(fwd) Who is responsible for the ccsids.net ("Code page information") website?
This showed up on bit.listserv.ibm-main and I think it would be of general interest. This is cc-ed to the original poster including the normal IBM-MAIN boiler plate. Clark Morris For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN On Fri, 25 Feb 2022 01:39:07 -0800 (PST), in bit.listserv.ibm-main "graham.h...@gmail.com" wrote: >Who is responsible for this website? > >http://ccsids.net/ > >Whoever it is, I'd like to say, "Thanks!". > >From that site: > >> [for the] sake of preservation of what I feel is important information in >> the public interest.?I do not work for IBM, and have not ever worked for IBM >> as of the time of writing. > >There are files on that site that used to be published on the now-defunct IBM >Globalization site. > >I also want to thank whoever (same person?) put those files on this public FTP >site: > >http://ftpmirror.your.org/pub/misc/ftp.software.ibm.com/software/globalization/gcoc/attachments/ > >Numerous topics in IBM Docs cite numeric character set identifiers. For >example, the z/OS 2.5 topic Creating ISPF code page translation tables: > >https://www.ibm.com/docs/en/zos/2.5.0?topic=dm-creating-ispf-code-page-translation-tables > >But I can't find any docs still published by IBM that describe those character >sets. So, as far as IBM-published docs are concerned, those numeric character >set identifiers are "opaque": not (or no longer) backed by IBM-published >reference tables that describe what characters are in each set. > >Am I wrong about this? Does IBM still publish this information somewhere else? >For example, can anyone point me to an ibm.com URL for the following table of >characters in the character set 697: > >http://ftpmirror.your.org/pub/misc/ftp.software.ibm.com/software/globalization/gcoc/attachments/CS00697.txt > >Graham Hannington -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rexx routine to dump all variables when debugging?
On Thursday 17/02/2022 at 1:29 pm, Seymour J Metz wrote: Some brain-dead e-mail clients don't show headers; take outlook - please! The Usenet gateway was one way; articles posted to the news group were not propagated to the listserv. Has that changed? Yes. Now there is no Usenet gateway unless my news source is broken. Clark Morris -- 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: Thursday, February 17, 2022 9:38 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Rexx routine to dump all variables when debugging? On Thu, 17 Feb 2022, at 02:44, Farley, Peter x23353 wrote: It used to be that our actual email addresses showed in the listserv headers, but I guess they are trying to protect our identities. I can see some people's real email addresses in some posts here. They're sometimes in ordinary headers, as they always used to be. They're sometimes in the SPF (Sender Policy Framework) headers, but not every post contains those - dunno why. They're sometimes poorly disguised in message-ids too. It maybe depends on whether people are posting by usenet or email, or via a website portal, as well as the client they use. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Country of development was Re: More of LOG4J
On Wed, 26 Jan 2022 12:35:59 -0800, Tom Brennan wrote: >Those are things we don't like to talk about :) And even less talked >about: What's to stop a trusted ISV or even IBM from being hacked or >having a rogue employee that does the same? Does the country where the software is developed matter? In most countries, the citizen is required to place nation above employer. Clark Morris > >On 1/26/2022 11:41 AM, Gibney, Dave wrote: >> If I was a long term bad actor, or perhaps a nation/state, I might consider >> evaluating open source for useful/popular components. Then, contribute to >> their development, spread, and usefulness, while inserting subtle >> exploitable 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
Re: More of LOG4J
On Tuesday 18/01/2022 at 12:42 pm, Kirk Wolf wrote: Since I would guess that a majority of ibm-mainers would agree that open source is confusing and dangerous, here's a question: As someone who installed and modified JES2 exits from the CBT tape, modified HASP with British Rail and other contributions from the Michigan mods tapes and used another mods tape for an IEBCOPY replacement as well as being someone who contributed back to the Michigan Mods 1979 tape, the JES3 tape and the CBTTAPE, I would not call open source confusing and dangerous. Anything that is put on a system has to be maintained either in house or by some trusted party be it a vendor or an open source project. The user has to understand the supplier's notification and update process and be able to use it in their environment. There have been both open source fiascos and vendor related fiascos. Clark Morris Let's say that an organization wanted to prohibit open source. How would you go about it? Kirk Wolf Dovetailed Technologies http://dovetail.com -- 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: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS
On Friday 07/01/2022 at 4:41 pm, Seymour J Metz wrote: COBOL was supposed to be that, no? The use of "magic numbers" as levels in the DATA DIVISION totally blows away any claim that COBOL is English like or understandable to someone without training. 66 foo PIC X(10). The syntax of 66 is "66 FOO RENAMES ABLE [THRU DOG]." 77 bar PIC X(10). 88 baz VALUE "S", "Y". Then there is the weird behavior of COMMENT. In COBOL ends a statement, *except* when that statement is a cooment, in which case it swallows the remainder of the paragraph. Later versions of COBOL introduce a better behaved comment syntax. That was the original NOTE statement replaced in later versions with of COBOL using * in column 7 for comment lines. I believe that there are further developments in the 2002 and 2014 standards that give other options which IBM may have implemented. Clark Morris -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Tony Harminc [t...@harminc.net] Sent: Friday, January 7, 2022 12:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ... Re: Top 8 Reasons for using Python instead of REXX for z/OS On Fri, 7 Jan 2022 at 11:45, Lionel B. Dyck wrote: I've been following this thread and one thing that has yet to appear, or I missed it, has to do with 4GL's and the drive, at one point, for languages that were more human oriented - those that could be written more like a normal sentence or phrase, and avoid the technical jargon/gobblygook/syntax. As I recall in the 1980's there were a few but nothing came of them, instead we have languages that have their own syntax, and which require extensive learning but nothing that allows a non-programmer to actually generate a complex business program. COBOL was supposed to be that, no? Managers could in theory at least read (if not write) a COBOL program and understand what it does, because it so (superficially) resembles English. From my experience, REXX has many of the 4GL goals as the syntax isn't overly complex and is something a non-programmer can comprehend rather easily. As has been previously mentioned in this thread, REXX can be more readily learned and used than the majority of the current languages. It isn't perfect but it works very well. Indeed. 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Chuck Norris and PTF's wasRe: zOSMF install of z/OS 2.5
On Tuesday 04/01/2022 at 10:53 am, Kurt J. Quackenbush wrote: Kurt Quackenbush -- IBM, z/OS SMP/E and z/OSMF Software Management Chuck Norris never uses CHECK when he applies PTFs. Is that why he always has to fight and be in great peril? Clark Morris d -- 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
Long time between IPLs a security risk? was Re: What is OVMSKERN?
>On Monday 29/11/2021 at 12:41 pm, Charles Mills wrote: Problem is long gone, >but FWIW this was 9 months after the last IPL. Given the need to apply security fixes that probably apply to SYS1.NUCLEUS or LPA modules, how is it possible to go 9 months without an IPL and maintain security? Clark Morris >Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Top 8 Reasons for using Python instead of REXX for z/OS
On Sunday 19/12/2021 at 9:41 am, René Jansen wrote: snip But wait: then it would not be the mainframe anymore, that controlled environment that people trust. In the coming years, you will regret that choice, when one of the Python libraries sprouts a ‘log4j’. If a site uses Apache, it probably has log4j> Given other things about the mainframe environment, the log4j vulnerability may not bite. Clark Morris snip Best regards, René. On 19 Dec 2021, at 00:54, David Crayford wrote: I agree with almost everything he says. Python is light years better than REXX. Of course, that's subjective but it IMO it's in a different league. I've been working with YAML configs recently and Python has a very nice YAML library. No such luck with REXX, especially classic REXX on z/OS. Just FYI, if anyone doesn't know, the person who wrote this article is an IBM employee, with almost 37 years with them. He is on LinkedIn at: -- 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: AWS Outage Analysis: December 7, 2021
On Sat, 11 Dec 2021 20:40:08 +, Bill Johnson <0047540adefe-dmarc-requ...@listserv.ua.edu> wrote: >https://www.americanbanker.com/news/why-some-banks-still-lean-on-mainframes > I can't read beyond the first 2 paragraphs on either Firefox or Edge. Clark Morris > > >Sent from Yahoo Mail for iPhone > > >On Saturday, December 11, 2021, 3:10 PM, Tom Brennan > wrote: > >And that's where we disagree. Banks will do whatever is most economical >that still meets their needs. If x86-cloud doesn't meet those >requirements today, they stay on the mainframe. Tomorrow... only the >shadow knows. > >People say OS/2 was far better in design, operation, and security than >Windows, but it's gone now. Sometimes the "best" system is simply what >everybody else is using. Got to go now because I just put in a betamax. > >On 12/11/2021 10:51 AM, Bill Johnson wrote: >> Do you put your DR placement right across the street from your data center? >> Consolidation is bad. Exposure for everyone in the same place is a disaster >> waiting to happen. Like last week. Its why truly important functions like >> banks dont do clouds. >> >> >> Sent from Yahoo Mail for iPhone >> >> >> On Saturday, December 11, 2021, 1:46 PM, Tom Brennan >> wrote: >> >> Of course... military has the money (the $500 hammer?) to have >> redundancy on their redundancy. Business installations normally can't >> justify those costs. >> >> However, I think if we looked close we both might be surprised at all >> the various baskets AWS has behind the scenes. But like any basket >> collection, there are always single points of failure. >> >> On 12/11/2021 6:06 AM, Bill Johnson wrote: >>> Youve just described what the mainframe does for an organization. But, I >>> dont want every organization to have its eggs in one basket any more than >>> I want every nuclear weapon in one silo. >>> >>> >>> Sent from Yahoo Mail for iPhone >>> >>> >>> On Saturday, December 11, 2021, 2:01 AM, Tom Brennan >>> wrote: >>> >>> I don't agree (surprise!) I've always advocated putting all your eggs in >>> one basket, and then taking really good care of that basket with >>> backups, DR, procedures, dual this, dual that, etc. >>> >>> On 12/10/2021 5:55 PM, Bill Johnson wrote: >>>> This paragraph concerns me. >>>> One of the founding principles of the early Internet design was >>>> decentralization by design, a single fault would not be able to take out >>>> everything. In a way, todays reliance on large cloud providers removes >>>> the benefits of decentralization; we rely on the scalability, cost >>>> effectiveness, and flexibility of todays SaaS and Cloud offerings yet we >>>> are potentially putting all of our eggs into one basket. This same >>>> statement applies to CDNs, as seen with the recent Akamai outage from this >>>> past summer. >>>> This was one of the drawbacks we experienced when our GM subsidiary (and >>>> all GM subsidiaries eventually) combined into EDS data centers. Charlotte >>>> was where ours was located. If the mainframe went down in Charlotte, >>>> multiple GM subsidiaries were screwed. Costing GM tens of millions in >>>> highly paid union labor twiddling their thumbs. >>>> If an ETSY business owner selling crocheted scarves has a 4 hour outage, >>>> its probably not that bad. If an auto plant, bank or brokerage, health >>>> care provider, insurance company, or airline is down for 4 hours, it could >>>> be disastrous. >>>> Clouds arent all theyre cracked up to be. >>>> >>>> >>>> Sent from Yahoo Mail for iPhone >>>> >>>> >>>> On Friday, December 10, 2021, 8:00 PM, Mark Regan >>>> wrote: >>>> >>>> Since this topic is still somewhat active, I thought I'd forward this link. >>>> >>>> https://www.thousandeyes.com/blog/aws-outage-analysis-dec-7-2021 >>>> >>>> Regards, >>>> >>>> Mark Regan, K8MTR, EN80tg >>>> CTO1 USNR-Retired (1969-1979 active; 1979-1991, reserves; including two >>>> years with the Ohio Air National Guard) >>>> Nationwide Insurance, Retired, 1986-2017 (z/OS Network Software Consultant) >>>> Email: marktre...@gmail.com >>>> LinkedIn: https://www.linkedin.com/in/mark-t-regan >>>&g
Re: AWS Outage Analysis: December 7, 2021
On Saturday 11/12/2021 at 4:33 pm, Bill Johnson wrote: Banks will never do what’s economical at the expense of risk. Mitigating risk is what banks do. The mainframe continues to get MORE ECONOMICAL, safer, more uptime, faster. The clouds have been around for a decade or more and how many banks have transitioned to the public cloud from a mainframe? Capital One? Clark Morris Sent from Yahoo Mail for iPhone On Saturday, December 11, 2021, 3:10 PM, Tom Brennan wrote: And that's where we disagree. Banks will do whatever is most economical that still meets their needs. If x86-cloud doesn't meet those requirements today, they stay on the mainframe. Tomorrow... only the shadow knows. People say OS/2 was far better in design, operation, and security than Windows, but it's gone now. Sometimes the "best" system is simply what everybody else is using. Got to go now because I just put in a betamax. On 12/11/2021 10:51 AM, Bill Johnson wrote: Do you put your DR placement right across the street from your data center? Consolidation is bad. Exposure for everyone in the same place is a disaster waiting to happen. Like last week. It’s why truly important functions like banks don’t do clouds. Sent from Yahoo Mail for iPhone On Saturday, December 11, 2021, 1:46 PM, Tom Brennan wrote: Of course... military has the money (the $500 hammer?) to have redundancy on their redundancy. Business installations normally can't justify those costs. However, I think if we looked close we both might be surprised at all the various baskets AWS has behind the scenes. But like any basket collection, there are always single points of failure. On 12/11/2021 6:06 AM, Bill Johnson wrote: You’ve just described what the mainframe does for an organization. But, I don’t want every organization to have its eggs in one basket any more than I want every nuclear weapon in one silo. Sent from Yahoo Mail for iPhone On Saturday, December 11, 2021, 2:01 AM, Tom Brennan wrote: I don't agree (surprise!) I've always advocated putting all your eggs in one basket, and then taking really good care of that basket with backups, DR, procedures, dual this, dual that, etc. On 12/10/2021 5:55 PM, Bill Johnson wrote: This paragraph concerns me. One of the founding principles of the early Internet design was decentralization – by design, a single fault would not be able to take out everything. In a way, today’s reliance on large cloud providers removes the benefits of decentralization; we rely on the scalability, cost effectiveness, and flexibility of today’s SaaS and Cloud offerings yet we are potentially putting all of our eggs into one basket. This same statement applies to CDNs, as seen with the recent Akamai outage from this past summer. This was one of the drawbacks we experienced when our GM subsidiary (and all GM subsidiaries eventually) combined into EDS data centers. Charlotte was where ours was located. If the mainframe went down in Charlotte, multiple GM subsidiaries were screwed. Costing GM tens of millions in highly paid union labor twiddling their thumbs. If an ETSY business owner selling crocheted scarves has a 4 hour outage, it’s probably not that bad. If an auto plant, bank or brokerage, health care provider, insurance company, or airline is down for 4 hours, it could be disastrous. Clouds aren’t all they’re cracked up to be. Sent from Yahoo Mail for iPhone On Friday, December 10, 2021, 8:00 PM, Mark Regan wrote: Since this topic is still somewhat active, I thought I'd forward this link. https://www.thousandeyes.com/blog/aws-outage-analysis-dec-7-2021 Regards, Mark Regan, K8MTR, EN80tg CTO1 USNR-Retired (1969-1979 active; 1979-1991, reserves; including two years with the Ohio Air National Guard) Nationwide Insurance, Retired, 1986-2017 (z/OS Network Software Consultant) Email:marktre...@gmail.com LinkedIn: https://www.linkedin.com/in/mark-t-regan -- 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...@lists
Is the mainfrrame cloud more reliable? was Re: AWS is down.
On Thu, 9 Dec 2021 10:55:08 -0800, Ed Jaffe wrote: >On 12/8/2021 5:40 AM, Doug wrote: >> I have watched this thread, and there is simply one thing most of us >> are missing. >> This is a MF forum. For years, we have been subjected to "oh using the >> (insert new technology) is so much better than these old obsolete >> mainframes." And we have universally warned not to drink the Kool-Aid. >> >> So excuse us a bit of satisfaction when the one of these "master of >> the universe" technologies has a problem that renders it mortal, like >> these old, obsolete mainframes. > >Absolutely justifiable, especially when the platform being derided has >*explicitly* positioned themselves as your MORTAL ENEMY: How reliable is IBM's z related cloud offering? How many of the mainframe shops are in practice old and obsolete due to management policy? How many shops have COBOL coding standards last updated with either COBOL 68 (ANS COBOL) or COBOL 74 (COBOL VS)? In my opinion one of the greater risks of the cloud is that the appropriate national government may compel the provider be it AWS, IBM, Microsoft, etc. to give said government access to an organization's data without notifying the organization. I think I read somewhere that the US Patriot act may authorize this and I believe that this is probably not unique to the United States. > >https://www.datacenterknowledge.com/cloud/aws-out-kill-mainframes Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Long time between IPLs a security risk? was Re: What is OVMSKERN?
On Monday 29/11/2021 at 12:41 pm, Charles Mills wrote: Problem is long gone, but FWIW this was 9 months after the last IPL. Given the need to apply security fixes that probably apply to SYS1.NUCLEUS or LPA modules, how is it possible to go 9 months without an IPL and maintain security? Clark Morris Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: Monday, November 29, 2021 5:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: What is OVMSKERN? The only time I've noticed is while the system is coming back up from an IPL, OMVSKERN IIRC are the processes that execute from the /etc/rc to start some OMVS services -- 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: Reliable source for slang term "noodle picker"?
I also heard the term noodle stuffer at SHARE. Clark Morris On Sunday 31/10/2021 at 12:33 am, Seymour J Metz wrote: I never met anybody who talked about the 2321 and didn't use the terms. From: IBM Mainframe Discussion List on behalf of Bill Ogden Sent: Saturday, October 30, 2021 11:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Reliable source for slang term "noodle picker"? From:Seymour J Metz Subject: Reliable source for slang term "noodle picker"? One of the wiki editors has removed mention of the term "noodle picker" from [[IBM 2321 Data Cell]] with the explanation >"Really remove unreferenced OR". Does anybody have a reliaible source for this usage that I can cite? I doubt there is an "official"source for this term, but it was a commonly used slang term at the time. (This comment is from an old old timer who actually programmed and used a noodle picker a long time ago. One thing we learned early: if possible, keep datasets open and avoid the need to access a VTOC often. ) 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IPL's POR's frequency
If Brian's sites only IPL once a year or less frequently, how are fixes to LPA modules applied? other fixes requiring an IPL? I was impressed with maintenance on the Tandem system (now HPE non-stop) where maintenance was just a simple operator procedure. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Is the feed to bit.listserv.ibm-main down?
Is the feed to bit.listserv.ibm-main down. I have seen nothing from it for days now. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: is it possible to allocate two dd to same temp file ?
[Default] On 2 Sep 2021 18:37:59 -0700, in bit.listserv.ibm-main skol...@us.ibm.com (Sri h Kolusu) wrote: >> I have used >> >> //SORTIN DD DSN=&,DISP=(OLD,PASS) >> //SORTOUT DD DSN=& >Clark Morris, > >Please don't ever do that with a COPY operation. For SORT operation you >would be OK to refer the same file but for a copy operation it is not >recommended as it can cause lost or incorrect data and we do document that >restriction. Not to mention that it would be a waste of time even if somehow it did work. It is in the same category as having 2 DDs pointing to the same file with both OPENed OUTPUT. Clark Morris > >For a copy application, the SORTIN data set should not be the same as the >SORTOUT data set or any OUTFIL data set because this can cause lost or >incorrect data or unpredictable results. > >https://www.ibm.com/docs/en/zos/2.4.0?topic=statement-general-coding-notes > > >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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: is it possible to allocate two dd to same temp file ?
[Default] On 2 Sep 2021 07:12:26 -0700, in bit.listserv.ibm-main
charl...@mcn.org (Charles Mills) wrote:
I have used
//SORTIN DD DSN=&,DISP=(OLD,PASS)
//SORTOUT DD DSN=&I would guess that by "fixed file" the OP means "a hard-coded DSN as opposed
>to a system temp DSN."
>
>Can one allocate two DD's to the same temp dataset? Would the following work?
>(Untested)
>
>//DD1 DD DISP=NEW,DSN=
>//DD2 DD DDNAME=DD1
>
>I have never done that. I have only used DDNAME= in the situation where I
>wrote to that DD rather than the referred-to DD name.
>
>Charles
>
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>Behalf Of Paul Gilmartin
>Sent: Thursday, September 2, 2021 6:10 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: is it possible to allocate two dd to same temp file ?
>
>On Thu, 2 Sep 2021 01:00:11 -0500, Weizman arbel wrote:
>
>>i want to free one of them (sortout)
>>and browse the file from the second dd.
>>( At the moment i am alloc 2nd dd copy the first and free the first )
>>( I do not want a fixed file )
>>
>>
>Perform the first allocation with:
>CALL BPXWDYN 'ALLOC RTDSN(D) RTVOL(V) ...'
>
>Reallocate with:
>CALL BPXWDYN 'ALLOC DSN('D') VOL('V') ...'
>
>What do you mean by 'fixed file'?
>
>-- 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
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Secondary sources for DFP and DFSMS
[Default] On 12 Aug 2021 10:00:05 -0700, in bit.listserv.ibm-main wilc...@us.ibm.com (Glenn Wilcock) wrote: >We've been vexed with this for some time. We, the DFSMS org, have wanted to >update this for some time. But, we've run into these same issues, probably >even more so since we are the product owners. So, first, thanks so much for >working on this! SHARE presentations are a good idea, but wondering if since >those are created by the product owners, if they will pass the litmus test. >I've thought about Redbooks since we sometimes get non IBMers as authors, but >didn't find any offhand that weren't written by IBMers. Those familiar with >Wikipedia, can a secondary resource come from someone within the IBM company, >but not directly related to the referenced products? If so, then the 'ABCs of >IBM Systems Program Volume 3', is a great reference. Outside of these >sources, our google searches haven't provided much as far as secondary sources >besides billable educational offerings. Glenn The user experience sessions at SHARE, Guide, etc. might be acceptable. Clark Morris > >-- >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: D U o a 1052 was Re: Serverpac installs January 2022 and beyond - Requests
[Default] On 26 Jul 2021 13:16:58 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >As I recall the only 1052 for use as a S/360 console was the 1052-7. I believe >that the 3210 also used the "golfball" but that the 3215 and 3287 had dot >matrix impact printers. > >Having COM in those days sounds like luxury; I'm envious. On one occasion, I used the fiche to show our operations manager that HASP cancelled a job and that neither the night shift operator nor had anything to do with it. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: D U o a 1052 was Re: Serverpac installs January 2022 and beyond - Requests
[Default] On 26 Jul 2021 06:37:53 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >Lot's of OS/360 MVT systems used a 1052-7, but that's not MVS. Did you >actually use the 3287 as a hardcopy console rather than for copying screens >and for applications? As I recall from around 40 years ago, we had the Selectric (bouncing ball) version of the 1052 on our mod 30, 40 and 65 systems. With long displays it quickly went down hill. I am fairly certain that the 3287 was our hardcopy device on MVS although at this late point I don't recall how much console traffic was routed to it. Starting with MVT we also printed SYSLOG to Fiche once a day. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
D U o a 1052 was Re: Serverpac installs January 2022 and beyond - Requests
[Default] On 25 Jul 2021 14:56:33 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >Did you ever see a 1052-7, or even a 3210, on an MVS system? Admiitedly the D >U message flood is a nuisance even on a 3270, but every shop that I saw used >3066 and 3270 for consoles, with hardcopy on syslog and no keyboard-printer >consoles. Was anybody here on a S/370 that used a 3210 or 3215 as an MCS >console? This was a 1052 on a 360/65. As I recall we graduated to a 3287 on our 4341. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Serverpac installs January 2022 and beyond - Requests
[Default] On 25 Jul 2021 06:42:01 -0700, in bit.listserv.ibm-main mwa...@us.ibm.com (Marna WALLE) wrote: >Brian, >Concerning small environments, does having z/OS (and z/OS V2.5) available to >all participating ISVs count as part of our early programs? Whereby they >could use z/OS V2.5 and z/OSMF in their own environment, or use it as a z/VM >guest? Does it count that these same ISVs, who can run in their own very >small environments on their own purchased HW, have had z/OSMF for quite a >while and we've delivered PTFs to help with the performance in those >environments because of their z/OSMF feedback? Does it count that any early >customer in the z/OS V2.5 release program can and do have small sandbox >systems, on which they perform their installation and service work? Does >having the function testing for z/OS V2.5 across all the z/OS Development labs >as z/VM guests count, with these environments sometimes being smaller than a >zPDT? I am wondering if some of the problem is the inappropriate default. I remember putting a zap on a console display module so that the default was 1 not 100 when a display unit command was issued.. The result of displaying 100 device statuses on a 1052 (deserving of the sledgehammer award) bouncing ball console printer was painful. This lasted from MVT well into MVS and was the subject of a requirement. If it takes 300 concurrent threads to run the default of 100 qualifies for being inappropriate. Also someone whose talent is improving systems performance may be needed. I was the type of person who would not have designed a good system but I could in many cases drastically improve the performance of an existing systems, preferably in COBOL although I did a speed up a couple of assembler programs. Clark Morris > >I do understand that you are unhappy with the choice of using z/OSMF for z/OS >V2.5 after Jan 2022. I'm not sure there's anymore I can offer. We have been >moving in this direction for a very long time. > >-Marna WALLE >z/OS System Installation and Upgrade >IBM Poughkeepsie > >-- >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
Excessive resource use was Re: Serverpac installs January 2022 and beyond - Requests
[Default] On 23 Jul 2021 21:21:19 -0700, in bit.listserv.ibm-main brian_wester...@syzygyinc.com (Brian Westerman) wrote: >Did you think to have even ONE of those early sites be one with a small >processor (single CPU) like a low end single CPU z/13, z14 or z15? Most >likely you didn't and that's very sad. A good percentage of "new" clients >that IBM has added over the past 5 to 8 years are in that boat and IBM has >decided to set sail without them. In addition to the resource use by z/OSMF, at the last SHARE Tom Ross reported that the current COBOL compile takes significantly more resources. Since IBM is moving to common compiler backends, has this become a problem for small shops? Clark Morris > >I have no doubt that the early customers represented vast swaths of >geographies and industries, but how low did you guys dip to test with a >"small" site. The ones IBM called strategic so that they would not go to Open >Systems and instead go with a small box and z/OS? > >It's very disappointing. Not all of the people IBM is ignoring have access to >large and small boxes like I do, if you have a small box and want to upgrade >after January to 2.5 from say 2.3, they will not be able to do it without >beefing up their machine or coming to someone like us to do it for them. I'm >not complaining about the business that IBM is pushing my way, but I think >it's sad that IBM appears to care very little about the damage (via >frustration) they are about to do. Some will buy an upgraded box, but many >will simply drop their mainframe path in favor of some other direction (away >from z/OS). > >Brian > > >On Fri, 23 Jul 2021 15:24:10 -0500, Marna WALLE wrote: > >>Brian, >>>> Some of the problem here is that you are telling me what "will" be there, >>>> but I don't have anything that actually shows that or even implies it for >>>> z/OSMF for z/OS. I don't even have the workflows to verify anything. >> >>For the z/OS Workflows that you haven't seen yet, they are Workflow steps >>that are submitting the same JCL jobs that you used to submit through the >>ISPF interface and should be familiar with today. Meaning, instead of using >>an ISPF panel to submit the job, you will now submit those same jobs from the >>z/OSMF Workflow interface. That is the difference. The jobs remain the same, >>in probably 99.99% of the cases. They are being converted from ISPF JCL >>skeletons (SCPPSENU) to z/OSMF Workflow JCL templates (XML). So yes, you >>haven't seen them in their XML format, but you certainly have seen them when >>they were JCL skeletons. And remember, every single Workflow step JCL that >>is submitted is able to be edited from z/OSMF, just like it was with the >>CustomPac dialog. >> >>Might there be a conversion error to XML? Yes, of course that is possible. >>But that is why we have my second comment below... >> >> >>>> People won't have much time between Late September and January to discover >>>> and correct all of the bugs. >> >>For each z/OS new release, and V2.5 more than ever, there are early customer >>programs. The release level early program for z/OS V2.5 has its main focus >>on the installation of and upgrade to z/OS V2.5. We understood that the >>installation process would be different and wanted as much exposure, testing, >>and validation in customer environments before it GAs. We have early >>customers that represent many different industries and geographies. Each of >>these customers has installed with a z/OS V2.5 z/OSMF ServerPac. Not a >>single one of them used the old ISPF ServerPac. >> >>-Marna WALLE >>z/OS System Install and Upgrade >>IBM Poughkeepsie >> >>-- >>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: EXTERNAL: Coding for the future
[Default] On 18 Jun 2021 08:57:44 -0700, in bit.listserv.ibm-main robhbrid...@gmail.com (Bob Bridges) wrote: >Ack! To my mind > > if fx then >do > ntim=ntim+1 >end > else >do > nres=nres+1 >end > >...is much harder to read than > > if fx then ntim=ntim+1 >else nres=nres+1 As a retired COBOL programmer used to meaningful data names I have found one condition of a compound conditional or 1 verb per line made things easier to modify and also to read. I tried to keep data names to 15 bytes or fewer and didn't use qualification as much as I would have liked because of COBOL's verbose way of handling it. Clark Morris > >--- >Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > >/* -from _The Voyage of the Dawn Treader_ by C S Lewis: >Eustace: In our world a star is a huge ball of flaming gas. >Ramandu: Even in your world, my son, that is not what a star is but only >what it is made of. */ > >-Original Message- >From: IBM Mainframe Discussion List On Behalf Of >Crawford, Robert C. >Sent: Wednesday, June 16, 2021 09:23 > >It's a small thing, but I now longer try to cram as much code into line as I >can. Now I put spaces between operators and variables and after commas. I >also put the clauses following "THEN" and "ELSE" on another line. > >Oh, and I used to this: >LOOP MVC HERE,THERE > >And now do this: >LOOP DS 0H >MVC HERE,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: U 4087 abend
[Default] On 7 Jun 2021 15:25:53 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >After all, the compilers, run time environments and utilities haven't been >using user ABEND codes for much more than half a century. > What I object to is LE obscuring the original abend code with an abend code that doesn't have a 1 to 1 relation to the original abend. A U4xxx-S0C7 message would be adequate. In regard to the application programmer in the original posting, Has he or she looked at all of the documentation such as CEEDUMP which as I recall has the original abend code? Is that programmer knowledgeable enough to know that a S0C7 is an application error 99.999 percent of the time (there may be a rare instance where it isn't). Clark Morris > >-- >Shmuel (Seymour J.) Metz >http://mason.gmu.edu/~smetz3 > > >From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of >Charles Mills [charl...@mcn.org] >Sent: Monday, June 7, 2021 5:08 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: U 4087 abend > >Well, the LE folks did not do anything for the clarity of this issue. I would >call an LE failure a system ABEND, but they are all U ABENDs. > >Charles > > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of zMan >Sent: Monday, June 7, 2021 10:56 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: U 4087 abend > >Well, for my money, any ABEND starting with U *must *be a system ABEND. >Those ones starting with S are clearly something else. > >On Mon, Jun 7, 2021 at 12:36 PM Seymour J Metz wrote: > >> Did the developer read the message description and look at the dump? Did >> he give a cogent reason for believing it was a systems error? If not, then >> the smart money says that it's his error. >> >> "Who knows, the horse might learn to sing." >> >> I would look for storage overlay, but that's not the only thing that >> could cause recurse condition handling. >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf >> of Bill Giannelli [billgianne...@gmail.com] >> Sent: Monday, June 7, 2021 11:41 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: U 4087 abend >> >> we have a job that keeps abending in an application program that the >> developer insists is a "system" issue. what does a U 4087 abend indicate? >> thanks >> Bill >> >> -- >> 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: U 4087 abend
[Default] On 7 Jun 2021 14:08:29 -0700, in bit.listserv.ibm-main charl...@mcn.org (Charles Mills) wrote: >Well, the LE folks did not do anything for the clarity of this issue. I would >call an LE failure a system ABEND, but they are all U ABENDs. What does the CEE dump say? One of the LE abends is for a trapped S0C7. U4087 may also indicate inability to produce error messages. This one from what I gathered using a search engine is a little more obscure. Clark Morris >Charles > > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of zMan >Sent: Monday, June 7, 2021 10:56 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: U 4087 abend > >Well, for my money, any ABEND starting with U *must *be a system ABEND. >Those ones starting with S are clearly something else. > >On Mon, Jun 7, 2021 at 12:36 PM Seymour J Metz wrote: > >> Did the developer read the message description and look at the dump? Did >> he give a cogent reason for believing it was a systems error? If not, then >> the smart money says that it's his error. >> >> "Who knows, the horse might learn to sing." >> >> I would look for storage overlay, but that's not the only thing that >> could cause recurse condition handling. >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf >> of Bill Giannelli [billgianne...@gmail.com] >> Sent: Monday, June 7, 2021 11:41 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: U 4087 abend >> >> we have a job that keeps abending in an application program that the >> developer insists is a "system" issue. what does a U 4087 abend indicate? >> thanks >> Bill >> >> -- >> 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
My opinion of COND was Re: Best catch up resources for MVS / ZOS Technologies
[Default] On 18 May 2021 17:15:54 -0700, in bit.listserv.ibm-main ponce...@bcs.org.uk (CM Poncelet) wrote: >With all due respect, anyone who has difficulty coding JCL COND= >statements should consider *not* working with IBM mainframe systems. as someone who had to play cute games with COND= I would consign the designers of it to the same hell as the designers of Little Endian which I consider to be store scrambled. This latter idiocy means that there has to be big-endian UTF-16 and little-endian UTF-16. Clark Morris > >All boolean conditional execution steps can be handled using only COND= >statements. I submitted a paper on this & it was published in >"Computing" in 1989. I would but cannot attach it, as uploading PDF >files to this discussion list is not permitted. > >No sysprog worth his salt has ever had a problem with coding JCL COND= >statements. > >Likewise IF/THEN statements belong in "JCL for dummies" - as do symbols >in JCL and SYSIN. Ditto IF/THEN in assembler. > >Chris Poncelet (r) > > >. >On 18/05/2021 14:02, Charles Mills wrote: >> Yeah, and IF/THEN is slightly better than COND= >> >> Also symbols in SYSIN data. >> >> Charles >> >> >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of Steve Horein >> Sent: Tuesday, May 18, 2021 5:35 AM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: Re: Best catch up resources for MVS / ZOS Technologies >> >> I would argue JCL got better when symbols were allowed! :-) >> https://www.ibm.com/docs/en/zos/2.4.0?topic=es-symlist-parameter >> >> On Mon, May 17, 2021 at 10:46 PM Charles Mills wrote: >> >>> Steve, let me wade in here and suggest some big picture. I think SHARE and >>> such is great for the details. >>> >>> What has changed since 2001? An idiosyncratic, IMHO list: >>> >>> - In 2001 SNA was yielding to TCP/IP. That transition has continued. An >>> awful lot of mainframe connectivity is now TCP/IP. Lots and lots of >>> Internet connectivity to the mainframe. >>> - Security is huge. Encryption is hot. Zero Trust is the buzzword of the >>> month. >>> - Everything is of course bigger. Z hardware goes up to what? 4TB real? >>> Someone will correct me if that is wrong. >>> - Tape drives have pretty much gone away. They live on as virtual, >>> emulated-on-DASD tape drives. >>> - The Cloud. Read any airline magazine for the latest. >>> - Remember VM? It was pretty moribund in 2001. It has found new life >>> hosting thousands of Linux instances. Yes, Linux running like a champ on Z >>> hardware. Mainframe Linux is huge. You can run Linux in a region of MVS in >>> a "container." >>> - Speaking of which, there is a Z box that will not IPL z/OS! It is called >>> Linux One. It's a mainframe with a bit hobbled somewhere such that >>> mainframe operating systems will not IPL, only Linux. >>> - Lots of new features in core MVS but you would fully recognize the >>> environment. If you sit down at a TSO/ISPF session it will seem like >>> nothing has changed. JCL has not gotten any better (or any worse, >>> thankfully). >>> - Remember the issue of "above the (24-bit) line"? It is still there, but >>> pretty much in the background. The new thing is data and execution "above >>> the (2GB/31-bit) bar." Lots of software products are exploiting data above >>> 2GB, and code can even run there, with lots of limitations. AMODE/RMODE 64. >>> - IBM JES3 is dead. Long live Phoenix JES3 plus. IBM ditched JES3, and >>> Phoenix picked it up. >>> - More emphasis on high level languages. Hardware design is being driven >>> by the Java folks and the compiler folks. Lots of new hardware >>> instructions. Hardware cycle times are not getting any faster, but >>> instructions do more per cycle. Caching getting more sophisticated and more >>> critical. The concept of "how long does an LR take" has totally >>> disappeared. It is a question with no answer other than "it depends." >>> >>> Anyone else want to weigh in? >>> >>> Charles >>> >>> >>> -Original Message- >>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >>> Behalf Of Gibney, Dave >>> Sent: Monday, May 17, 2021 6:58 PM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Re: Best catch up resources for MVS / ZOS Technologies >>>
Dr. Robert Rannie's diagram of NIP was Re: Diagram of MVS Control Blocks
[Default] On 24 Apr 2021 13:21:37 -0700, in bit.listserv.ibm-main techsupp...@quickref.com (Michael A. Shaw) wrote: >On 4/23/2021 3:43 PM, PINION, RICHARD W. wrote: >> Many years ago, 1982, I took my first MVS class, MVS Structure and Logic. >> One of >> the first handouts our class was given was a spaghetti diagram of MVS >> control blocks. >> Unfortunately, I threw mine away in 2016, when I thought my system >> programming >> days were over. > >I took that same two-week class in Chicago in 1980. The diagram in >question (as I remember it) was a joke, right? It was impossibly >complicated with curved lines and arrows and flowchart symbols all over >it. It was made to generate a chuckle, not teach actual logic flow. Were there ever any paper copies of Dr. Robert Rannie's diagram of NIP processing and if so are there any still around? Clark Morris > >I too had a copy once, but it's long gone. > >Mike > >-- >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
Answer is my reason for saying PDse not ready for prime time was Re: ServerPac Question
[Default] On 16 Apr 2021 15:55:46 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >If it;s needed to IPL then it must be PDS. AFAIK, anything that you >dynamically add after PDSE support is active can be PDSE. This answer shows why I believe someone should have had their head handed to them in the design of PDSE. That a basic data type - library isn't available at NIP is absurd and in my eyes makes PDSe not completely ready for prime time. This was like the mal-design of local SNA devices 327xs not being usable as console devices forcing my shop to have 2 non-SNA 3x74s for redundancy in the 1980s. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Record description converter
I would like to see a set of two way conversion tools that would convert COBOL copybooks to Assembler DSECTs and vice versa, SORT symbols to and from Assembler DSECTs, PL1 structures to and from Assembler DSECTs etc. If this were available it would be possible to convert COBOL record descriptions to their PL1 equivalent, Assembler DSECTs, SORT symbols, C Structures, etc. Data types not supported in a language would have comments (bits in COBOL for example). This would allow a shop to have a set of common descriptions across languages. I would have used this when I was working. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Any z/OS sandbox available for a university student I know?
[Default] On 16 Mar 2021 14:45:52 -0700, in bit.listserv.ibm-main 000433f07816-dmarc-requ...@listserv.ua.edu (Paul Gilmartin) wrote: >On Tue, 16 Mar 2021 19:57:59 +, Bill Johnson wrote: > >>There are quite a few colleges that offer mainframe classes & lots of young >>people working on it. Too many have bought the mainframe is dead idiocy. For >>decades. The mainframe still processes the vast majority of important work >>and will for decades to come, long after most of us here are gone. >>... >Or, make python, javascript, ruby, etc. available under z/OS for a >competitive cash outlay. > >The recent "COBOL ... change in behavior ..." thread might provoke a >feeding frenzy among the airline magazines. > If the numeric field was actually PIC S99 in which case the code is correct else it was PIC 99 as posted in which case the code should be APARed. Clark Morris > >>On Tuesday, March 16, 2021, 3:45 PM, Brian Chapman wrote: >> >>In my opinion, it's a shame that it is this difficult to find a free >>academic platform for individuals like the one you described. Master the >>Mainframe is a great place to start, but it does not go deep enough. >>There's a reason why preteens are writing python, javascript, ruby, etc. >>IBM needs to change their perspective and culture to encourage >>young individuals to the mainframe. > >-- gil > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL V6.2 possible change in behavior with recent patch level
[Default] On 12 Mar 2021 09:34:42 -0800, in bit.listserv.ibm-main frank.swarbr...@outlook.com (Frank Swarbrick) wrote: >Thanks for this info. Makes me feel better (for whatever reason). >We actually had some guesses that the issue was caused by migrating from COBOL >V4 to V6, even though that was done months ago. (The "bad code" was added >after the migration, and thus had never run under COBOL V4). > >The unfortunate thing is (this is my understanding, anyway), the bug in the >application showed up in testing but was ignored/bypassed as an "environment >issue", which of course was a bad assumption. Are you sure that as-num is defined as PIC 99 as opposed to S99. The code you show is valid for PIC S99 but not PIC 99. Clark Morris > >We're now discussing using the NUMCHECK option in development, and I think >that will turn up a lot of these cases. Which is a good thing. > >Frank > > > >From: IBM Mainframe Discussion List on behalf of >Dylan Perry <0300eb0a0e16-dmarc-requ...@listserv.ua.edu> >Sent: Thursday, March 11, 2021 10:32 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: COBOL V6.2 possible change in behavior with recent patch level > >ZONEDATA(MIG) is meant to provide compatibility with the NUMPROC(MIG) option >in pre-V5 versions. COBOL 4.2 with NUMPROC(MIG) abends with a S0C7 with the >following instructions:- > >001154 IF > 0004CC 4DE0 9152 BAS 14,338(0,9) TGT TEST > INFORMATION AREA +10 > 0004D0 GN=19EQU * > 0004D0 F211 D110 8010 PACK 272(2,13),16(2,8) TS2=0 > AS-NUMS > 0004D6 F911 D110 A0B2 CP272(2,13),178(2,10) TS2=0 > PGMLIT AT +162 > >This APAR explains that in versions 5 to just before the recent 6.2 fix it was >"incorrectly" fixing the S0C7:- > >https://www.ibm.com/support/pages/apar/PH28379 > >-- >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: COBOL V6.2 possible change in behavior with recent patch level
[Default] On 11 Mar 2021 11:52:56 -0800, in bit.listserv.ibm-main frank.swarbr...@outlook.com (Frank Swarbrick) wrote: >We recently applied patches up through September 2020 to our Enterprise COBOL >V6.2 compiler. Prior to this we had patches through September 2019. This >appears to have changed how some code is generate, even though the compiler >options have not changed. > >Take the following example: > > 01 ipt. > 05 as-char pic xx. > 88 as-char-10value '10'. > 05 as-nums redefines as-char > pic 99. > 88 as-num-10 value 10. > >Code checking the as-num-10 condition is generating the following code with >the "current" patch level: If as-nums is PIC 99 and not PIC S99, the generated code is flat out wrong. The field can only be x'F1F0" and x'F1C0' would be in error. Clark Morris > >COBOL V6.2 NUMPROC(NOPFD) ZONEDATA(MIG) > >21: 002200 if as-num-10 > 0001C8 F211 D138 9018 21PACK312(2,R13),24(2,R9) > # AS-NUMS > 0001CE F911 D138 31EC 21CP 312(2,R13),492(2,R3) > # +492 > 0001D4 A764 0016 21JNE L0006 > >This causes a situation where if "as-nums" is not a valid zoned-decimal field >it's causing a data exception (S0C7) on the CP instruction. >While acknowledging that the code is "bad", or the data is bad (depending on >how you look at it), we're still wondering what changed with the recent >patches. > >While I can't (easily) recover the compiler to the previous level, I did test >with our COBOL V5.2 compiler, which is out of service and did not receive any >recent patches. The same code compiles to this: > >COBOL V5.2 NUMPROC(NOPFD) ZONEDATA(MIG) > >21: 002200 if as-num-10 > 00019E E300 8028 0095 21LLH R0,40(,R8) > # AS-NUMS > 0001A4 C00D F0F0 21OILFR0,X'F0F0' > 0001AA A70E F1F0 21CHI R0,0xf1f0 > 0001AE A764 000C 21JNE L0007 > >My guess is that prior to the patches COBOL V6.2 would have done something >similar. As you can see, it's using a CHI instead of a CP, and thus no S0C7. >It seems like V6.2 should not have changed its behavior in this regard. >Thoughts? Is this a new "bug" in COBOL V6.2? > >Frank > >-- >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: Large block interface for VB
[Default] On 7 Mar 2021 07:57:02 -0800, in bit.listserv.ibm-main reichman...@gmail.com (Joseph Reichman) wrote: >If you read a larger number of bytes into core lets say above the bar less >I/o should speed things up no ? > If you have a large enough number of buffers, the difference should be negligible. For QSAM I hope they would be above the line taking advantage of the 31 bit address space. Having oddball data sets which require special handling and maybe even EXCP will probably cost more time than you save. Playing with BUFNO and NCP are a better expenditure of time and effort. Clark Morris > >> On Mar 7, 2021, at 10:40 AM, Radoslaw Skorupka >> wrote: >> >> ?W dniu 06.03.2021 o 16:50, Laddie Hanus pisze: >>> LBI is available on DASD the largest block that will fit on 1 track, on the >>> 3390 thats about 56K. Logical record (LRECL) is still limited to 32760, >>> This is for new datasets being written. Existing datasets will read one >>> block per i/o and will be no larger than what written. this is for BSAM >>> read/check. manual DF/DSS Advanced services under the DEVTYPE macro will >>> has a table of largest blocksize per decice type >> >> The problem is I have never seen LBI block on DASD. >> Can I allocate such dataset using ISPF 3.2 or JCL DD ? >> Can I copy existing LBI dataset using IEBGENER or IDCAMS? >> >> It's more or less like long member names in PDSE. They exist, however I >> haven't found any. >> And I think it is not only my observation. >> >> From the other hand large blocks on tape are widely used and supported by >> existing system tools. >> >> Last, but not least: author of the thread wants better performance. I would >> not expect significant performance improvement by changing BLKSIZE =half >> track to whole track. >> >> -- >> Radoslaw Skorupka >> (looking for new job) >> Lodz, Poland >> >> -- >> 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
Are these auditors competent? was Re: Anyway to save ISRDDN output?
[Default] On 18 Feb 2021 05:12:25 -0800, in bit.listserv.ibm-main cvitu...@hughes.net (Carmen Vitullo) wrote: >I actually like the IBM health checker idea, I know I've been told over and >over it needs to be ISRDDN, but I really think it's because that's all they >know, they are lazy to say the least. As I suggested in a prior posting, I would investigate these auditors. If your postings reflect their knowledge and approach I would not have any confidence in their findings. As Peter Relson said D PROG,APF is more trustworthy than ISRDDN. However, they also should be interested in all PARMLIB members that can cause a library to be APF authorized as well as means of updating APF libraries. A competent auditor can help improve your system. An incompetent one can waste your and management's time and money and may even leave your system more vulnerable. Clark Morris >thanks > >Carmen Vitullo > > > >-Original Message- > >From: Peter >To: IBM-MAIN >Date: Thursday, 18 February 2021 6:50 AM CST >Subject: Re: Anyway to save ISRDDN output? > >If I were an auditor, I'd prefer an approach that is implemented by a >required base element of the operating system (where SDSF and, I think, >ISPF do not meet that criterion) > >That would cover: >-- hzsproc CHECK(IBMCSV,CSV_APF_EXISTS) >-- DISPLAY PROG,APF > >Or provide my own (if I trust myself) >-- a program I provided that issues CSVAPF REQUEST=LIST and surfaces the >output > >But that's just me. And I'm no auditor. > >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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Anyway to save ISRDDN output?
[Default] On 17 Feb 2021 11:18:10 -0800, in bit.listserv.ibm-main cvitu...@hughes.net (Carmen Vitullo) wrote: >you took the words right out of my mouth, I told our team auditor rep to ask >them, "how to we use ISRDDN and provide the output you require", unfortunately >this person is afraid to rock the boat, I on the other hand had some good >teachers and was taught I need to be a pain, be a fly in the ointment ! > Based on this thread, I seriously doubt that these auditors are capable of doing a competent job of assessing risk. You could spoof ISRDDN by using a STEPLIB in the logon PROC. I would trust a console display of D PROG,APF,ALL more. Incidentally what is the status of modules? They remind me of an auditor who in the 1980s after being told we had effectively no security (by me and then my boss who put it in management terms) was more concerned with the fact we were running JES3 on a single computer system. It might be worthwhile to research this company. Clark Morris > >Carmen Vitullo > > > >-Original Message- > >From: Lizette >To: IBM-MAIN >Date: Wednesday, 17 February 2021 1:09 PM CST >Subject: Re: Anyway to save ISRDDN output? > >Then I would go back and say > >Please provide your tool to do this, as you do not want to trust one of mine > > > >-Original Message- >From: IBM Mainframe Discussion List On Behalf Of >Carmen Vitullo >Sent: Wednesday, February 17, 2021 11:59 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: Anyway to save ISRDDN output? > >Lizette, you are absolutely correct and this is one of the options I provided, >the only problem, the HITRUST contractor(s) tell us what commands, what tools >to use to provide them what they require. >they require us to use ISRDDN, any other tool or command, in their eye's can >be spoofed, faked > >Carmen Vitullo > > > >-Original Message- > >From: Lizette >To: IBM-MAIN >Date: Wednesday, 17 February 2021 12:49 PM CST >Subject: Re: Anyway to save ISRDDN output? > >Why not go to SDSF APF and list there? > >Or maybe in SDSF use CK and go to APF Health Check details. > >You can use either depending on what your Auditors need. > >The APF in SDSF can probably be captured with an ISFEXEC function. > >Lizette > > > >-Original Message- >From: IBM Mainframe Discussion List On Behalf Of >Carmen Vitullo >Sent: Wednesday, February 17, 2021 7:45 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Anyway to save ISRDDN output? > >We have a HI TRUST requirement to use ISRDDN (only) to report on APF datasets >and other system information. Is there a way to invoke ISRDDN and save the >output to a dataset? >We've tried ISRDDN APF then save but it does not provide the APF info I >requested. reading the find manual I don't see any options to allow us to save >the output, any ideas? >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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Learning the basics of SMP/E
[Default] On 15 Feb 2021 14:35:08 -0800, in bit.listserv.ibm-main scarra...@unicaja.es (Salva Carrasco) wrote: >The basic of SMP/E is: make a full backup first. And at every step in the process that changes any of the data sets or CSIs except for receiving holddata. Clark Morris > >-- >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: question on enqueues
[Default] On 15 Feb 2021 15:37:38 -0800, in bit.listserv.ibm-main rpomm...@sfgmembers.com (Pommier, Rex) wrote: >I have one that's puzzling me and I'm sure there's a simple solution/answer. >I'm seeing 2 jobs running on a single system that are hitting an enqueue >problem on a parmlib. The JCL in both jobs has DISP=SHR, yet one of the jobs >has an exclusive ENQ on the library. Here's the scenario: > I suspect the flash process does an exclusive ENQ on all data sets being flashed. Clark Morris >Job A is a system backup job. It does a bit of early processing, then runs an >FDRFlash of most of our disk, then runs FDR to back up the offline volumes >created in the flash as well as some volumes that weren't flashed. Once the >backup step is done (3 hours later) it does some more post backup processing. >There are 3 steps in the post processing that allocate this parmlib, all >allocating the same member - call it A.B.C.PARM(MEMB), all with DISP=SHR. > >Job B is a cyclical job that runs in a matter of a few seconds and runs every >5 minutes. It also has A.B.C.PARM(MEMB) DISP=SHR as well as A.B.C.PARM(MEMZ) >DISP=SHR in a different step. > >Timing: > >Job A started and was doing its preliminary work. >Job B started and ended successfully. >Job A does the flash step and starts the full volume dumps. >Job B comes along again and can't start because job A has an exclusive ENQ on >A.B.C.PARM. Job B does not start until job A has completed the last step with >A.B.C.PARM in the JCL. > >A couple other points are that A.B.C.PARM is on a volume that was flashed, so >the source volume wasn't part of the backup. The job steps in both jobs with >A.B.C.PARM in them are all conditional steps that actually didn't execute. > >So my question is what could have caused an ENQ change from SHR to OLD when >the JCL explicitly has SHR? > >TIA, > >Rex > >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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
VS COBOL II 1.3 differed from 1.4 was Re: Looking for an old OSVS Cobol II v1.3
[Default] On 19 Jan 2021 05:56:15 -0800, in bit.listserv.ibm-main 01304632a58d-dmarc-requ...@listserv.ua.edu (W Mainframe) wrote: >Guys, >I am planning to revival an old application written in OSVS Cobol II v1.3 >(it's important the correct release) for VMSP rel5 in my P370... Unfortunately >my cobol mdisk has some crc errors, I can't read it and there is no backup... >:(Anyone has this compiler available? There is no comercial focus... Are you looking for 1.3 which I think was still COBOL 74 standard as opposed to 1.4 which I think was the first to be the COBOL 85 standard? There were some noticeable changes in syntax and interpretation between the two standards. Clark Morris >ThanksDan > >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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Request for help with removing sequence numbers from PDS members
[Default] On 12 Jan 2021 08:42:24 -0800, in bit.listserv.ibm-main robert.ah.pr...@gmail.com (Robert Prins) wrote: >>snip > >And a general note: when using ISPF edit to remove sequence numbers from a >(large) number of (large) members, you might need to cater for the fact that a >PDS might need to be compressed at some stage in the middle of your processing! Use of update in place should work if all that is being done is sequence number stripping since the size of the member does not change. Clark Morris > >Robert > >PS: Please people, strip off all the unnecessary garbage from your replies... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Progam directory AD/Cycle C/370
[Default] On 6 Jan 2021 11:34:45 -0800, in bit.listserv.ibm-main r.skoru...@bremultibank.com.pl (R.S.) wrote: >W dniu 06.01.2021 o 09:19, Tom Ross pisze: >> snip > >Tom, >Thank you for the table. >Actually I found some table in COBOL Migration Guide manual >https://www.ibm.com/support/knowledgecenter/hu/SS6SG3_6.3.0/migrate/igympreab2.html > > >but your table is more detailed - I mean dates. >To make things more complex your table lack of third dimension ;-) I >mean MLC vs VUE flavours, which is technically irrelevant, but introduce >new PIDs (program numbers). >And this is good you preserved version numbering - that simplifies >identification. > >Funny fact: I vaguely remember 1999 and some official announcements >about OS/VS COBOL withdrawals which were obscure and incomprehensible >for me at the time. ;-) > >BTW: This is pure curiosity, however was there any COBOL life on earth >before 1974? I'm sure it was some COBOL, but it was really looong time >ago. Maybe different product packaging and numbering, etc. I used COBOL (19)61 and COBOL (19)63 on an RCA 301 in the 1963 - 1965 timeframe, then started with COBOL D on a 32K 360/30 with DOS progressing to COBOL F on either the 64K mod 30 or 128K mod 40. I think I have used most versions on OS360 through MVS/XA in the time frame 1977 - 1991 plus VS COBOL II release 1.4 (a major improvement) followed by either COBOL 370 or COBOL for MVS and VM. Clark Morris > >Regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMF Type65 - Determine who Deleted the Dataset
[Default] On 1 Jan 2021 07:37:00 -0800, in bit.listserv.ibm-main charl...@mcn.org (Charles Mills) wrote: >I am trying to recall. I think SMF 17 may be written for non-VSAM as well as >VSAM. The doc (V2R1 is what I happen to have open) says "Record type 17 is >written when a non-temporary DASD data set or a temporary DASD data set is >scratched." Would not seem to exclude VSAM. Type 17 is non-VSAM only. I think that type 65 is VSAM related only. The type 42s are after my active time but they may be of help. Clark Morris > >In my experience, the most frequent cause of "how come I don't see an SMF xx >record for such-and-such?" is the convoluted logic of SMFPRMxx TYPE/NOTYPE >SYS/SUBSYS logic. Do a D SMF,O and look very, very carefully at the output. It >sometimes turns out that at some point in history lost in the mists of time >someone said "we are filling up SMF with 65's from TSO" or some such logic and >turned SMF type 65 off for TSO. > >Charles > > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Jasi Grewal >Sent: Thursday, December 31, 2020 7:16 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: SMF Type65 - Determine who Deleted the Dataset > >Charles Thank You for taking the time to respond on New Year Eve and >unfortunately, the datasets in question are VSAM Datasets and would I see the >information for that. >Happy New Year to You and to All! >Regards, >Jasi G. > >-- >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: System Boost Question
[Default] On 28 Nov 2020 11:02:02 -0800, in bit.listserv.ibm-main gad...@malam.com (Gadi Ben-Avi) wrote: >We are to take delivery of a z15-t02. >I have a question about system boost. >A few months ago, as part of upgrading CICS, we shut down all of our CICS >regions in order to upgrade the CICS SVC. > >We are running z/OS v2.3 > >Could we use SYSTEM boost to make the process of shutting down the CICS region >and restarting them? >Would it be 'legal'? > Can you upgrade the CICS SVC without an IPL? Clark Morris >Thanks > >Gadi > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How to get CEEDUMP with DFSORT?
[Default] On 18 Nov 2020 15:56:00 -0800, in bit.listserv.ibm-main skol...@us.ibm.com (Sri h Kolusu) wrote: >> Thank you, I had read this. I expect that doing this will return me >> to the CEEDUMP behavior I had the other sort product. I was hoping >> for an option where the DFSORT termination would continue on to the >> LE termination. That was my specific question. Will, or can I get the >CEEDUMP? The normal setup for SYNCSORT used to the if invoked by JCL the SORT would abend upon error while if invoked by a program it would quit with a return code of 16 (in COBOL the code would be in SORT-RETURN. I am fairly certain given the COBOL manual the same is true for DFSORT. One simple way to see what would happen is to set up a simple COBOL program to sort a file on a signed packed decimal field and have invalid data in the test file. The program should test SORT-RETURN for 16 and abend if found. Clark Morris > >Dave, > >Generally if you have an error in COBOL , then Language environment SPIE >takes over and generates the CEEDUMP. So if your shop has IBM-supplied >default TRAP(ON,SPIE) , you would get CEEDUMP. > >> I still think I am better off setting ESTAE=NO as a default. I would >> rather my programmers can fix the error from the first run, rather >> than needing another failing run with debug options. > >If you intend to go with turning of ESTAE , then make sure that you only do >it for ICEAM2 environment so that only program invoked sorts have their >ESTAE disabled. Please do not turn it off for ICEAM1 environment. > >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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Non-L/E assembler program calling L/E Cobol program
[Default] On Tue, 17 Nov 2020 10:52:49 -0800 (PST), in bit.listserv.ibm-main Joe DeChirico wrote: >Hi > >I have a need for a non-l/e program to call an l/e cobol program, are there >any examples of this sort of call? > >Is it even possible? Others either have or will point you to the correct ways of doing what you want. You might consider replacing the Assembler program with a COBOL program because Enterprise COBOL is a lot more powerful than COBOL VS (the 1974 standard) and may well have all of the function needed. I suspect many shops may still be stuck in a COBOL VS mindset. If you want to discuss this offline, my e-mail is cfmt...@uniserve.com Clark Morris > >Thanks > >Joe DeChirico -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reference for NIH or Mellon multi-access SPOOL?
[Default] On 17 Nov 2020 09:24:13 -0800, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >Can anybody point me to documentation on the provenance of the NIH (HASP II >V3) or Mellon (HASP II V4) mods for mult-access SPOOL? There are citation >needed tags in https://en.wikipedia.org/wiki/Job_Entry_Subsystem_2/3 and I'd >like to include some. Thanks. Are cumulative JES2 mods tapes online? the MICHMODS MVT tapes of varying vintages? These might have what you want as might contemporary SHARE proceedings because they probably would have been subjects of sessions. The Mellon Bank mods may also be on early CBT tapes if they predate MVS. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JES2 Policies
[Default] On 4 Nov 2020 08:31:10 -0800, in bit.listserv.ibm-main joemon...@gmail.com (Joe Monk) wrote: >Radoslaw, > >I think what the OP is really saying is that certain accounts should be >restricted from certain jobclasses i.e. DEV cant use PROD jobclasses. So, >if they code a CLASS=X, but the account info says that they dont have >access to CLASS=X, then dump the job. If the system knows what classes are legal for a given account and resource requirement, then it should change the job class to a legal one rather than bounce the job. A submitter should be able to submit a job and based on the account and resources requested the system should assign the appropriate job class. That was how I designed my rewrite of the American Natural Resources EXIT 6 (In the ancient Philips Lighting mods on the CBT tape). Clark Morris > >OP: This has been around a long time, and is very mature... > >Joe > >On Wed, Nov 4, 2020 at 8:20 AM R.S. wrote: > >> W dniu 04.11.2020 o 13:10, Gadi Ben-Avi pisze: >> > Hi, >> > I've started looking into JES2 Policies. >> > >> > The current goal is to change a job's class or service class depending >> on certain values in the accounting information. >> > >From reading the manual, it seems that this is possible. >> > >> > Has anyone done something like this? >> > Is there a way to debug these policies? >> > >> > Is this feature mature enough to use? >> >> I dare to disagree ...with your goal. More precisely I disagree with >> your presentation of the goal. >> Does it really have to depend on account information? Why? >> >> That means user has to code something in the jobcard, in the first >> positional. So he may code CLASS= keyword as well, can't he? >> Maybe your accnt infor is already somehowe controlled (my guess, lack of >> information). However jobclass can be RACF-controlled. >> And this is quite mature way to control job classes and (indirectly) >> service classes. >> >> -- >> Radoslaw Skorupka >> Lodz, Poland >> >> >> >> >> >> == >> >> Je?li nie jeste? adresatem tej wiadomo?ci: >> >> - powiadom nas o tym w mailu zwrotnym (dzi?kujemy!), >> - usu? trwale t? wiadomo?? (i wszystkie kopie, które wydrukowa?e? lub >> zapisa?e? na dysku). >> Wiadomo?? ta mo?e zawiera? chronione prawem informacje, które mo?e >> wykorzysta? tylko adresat.Przypominamy, ?e ka?dy, kto rozpowszechnia >> (kopiuje, rozprowadza) t? wiadomo?? lub podejmuje podobne dzia?ania, >> narusza prawo i mo?e podlega? karze. >> >> mBank S.A. z siedzib? w Warszawie, ul. Senatorska 18, 00-950 Warszawa, >> www.mBank.pl, e-mail: kont...@mbank.pl. S?d Rejonowy dla m. st. Warszawy >> XII Wydzia? Gospodarczy Krajowego Rejestru S?dowego, KRS 025237, NIP: >> 526-021-50-88. Kapita? zak?adowy (op?acony w ca?o?ci) wed?ug stanu na >> 01.01.2020 r. wynosi 169.401.468 z?otych. >> >> If you are not the addressee of this message: >> >> - let us know by replying to this e-mail (thank you!), >> - delete this message permanently (including all the copies which you have >> printed out or saved). >> This message may contain legally protected information, which may be used >> exclusively by the addressee.Please be reminded that anyone who >> disseminates (copies, distributes) this message or takes any similar >> action, violates the law and may be penalised. >> >> mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 >> Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the >> Capital City of Warsaw, 12th Commercial Division of the National Court >> Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital >> amounting to PLN 169.401.468 as at 1 January 2020. >> >> -- >> 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: How can you change TCAS defaults using the TSOKEYxx PARMLIB member?
[Default] On 23 Oct 2020 15:01:21 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >Did you bounce TSO after the change? If I understood Sam's question, it was how do you change TCAS defaults by using TSOKEYxx which means to me that he expects TSO to come up after IPL with the values in TSOKEYxx, not the defaults and that this isn't happening. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSort to pull the latest record date
[Default] On 25 Sep 2020 10:25:23 -0700, in bit.listserv.ibm-main skol...@us.ibm.com (Sri h Kolusu) wrote: >> Given the obscurity of the control statements (quick tell me what >> field is 1,4,CH) why not write the thing in a language > >Clark, > >I have to respectfully disagree with you. The control statements for DFSORT >are not obscure and they are on the same level as following the >coding/syntax rules for a programming language. For example COBOL, you >would follow all the rules governing it. So why not do the same for DFSORT? What field is 1,4,CH? Why should an applications programmer have to know in 2020 that offset 5 in the COBOL data division map means 6 if it is a fixed block file and 10 if it is a variable block file? > >>> PL1 and COBOL both generate fairly efficient code and when >> the tool becomes more than one off wonder, someone else can pick up >> the program and have a fighting chance of understanding what was being >> done. > >Aren't the programs depending on the input file attributes? For example a >COBOL program written to handle a FB 80 byte file will NOT work with FB 100 >byte file. You need to write another program to handle it. With DFSORT >there is absolutely no change in the control cards for different LRECL as >long as the key fields are the same. For output you would be right about the COBOL program not being able to handle the change in record length but if RECORD 0 is coded on the FD for a QSAM input fixed block file, so long as the first n bytes are the bytes expected, the program will read whatever record length is in the DSCB and ignore the excess over what is described. Both the sort and the COBOL program would be invalidated if any of the displacements for fields that aree reference change. > >DFSORT has come a long way from being just a sort product. It can do a lot. > When I see coding in field displacement and length I am reminded of why I was very happy the company I was working got DYL280 to replace DYL260. I was a heavy user of DYL260 but the ability to use COBOL record descriptions and DYL280 record descriptions was a game changer. Just out of curiousity, assuming half track blocking, how much more efficient is the sort I-O than coding BUFNO=30? Clark Morris >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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Microsoft using IBM was Re: IBM splitting into two companies
[Default] On 12 Oct 2020 07:49:43 -0700, in bit.listserv.ibm-main charl...@mcn.org (Charles Mills) wrote: >I know they did 25-ish years ago. I personally saw it. Also an AS/400 -- their >corporate travel department ran on it. I would be astounded if Microsoft was running any of their business today on other than Microsoft operating systems or Linux on x86 and ARM hardware. Clark Morris > >Charles > > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Allan Staller >Sent: Monday, October 12, 2020 6:55 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: IBM splitting into two companies > >Classification: HCL Internal > >The dirty little secret is that MSOFT has a mainframe in the back office! > >-- >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: IBM splitting into two companies
[Default] On Sat, 10 Oct 2020 10:40:07 -0700 (PDT), in bit.listserv.ibm-main computer chyck wrote: >> snip much > >Cloud computing is alot like teenage sex - everybody is doing it (or wants to >do it) but nobody has a flippin' clue how to do it correctly!!! What I fear is that Amazon and Microsoft both have a far better idea of what cloud computing is and how to do it than does IBM. I also suspect that Amazon has all of their computing on their cloud and is very well aware of the need for high security and has worked very hard to achieve it. Microsoft based on my experience with their Knowledge Center (repository for fixes and the equivalent of PTF cover letters) seems to understand high availability better than IBM based on postings here on ibm-main. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: dataset allocation
[Default] On 8 Oct 2020 17:42:10 -0700, in bit.listserv.ibm-main reichman...@gmail.com (Joseph Reichman) wrote: >I have no idea who the sysorog is > >Honestly Im told to do something I try my best to accomplish my superiors >just tell me to ask different people > >I have come to the point no one wants to help so I take the attitude Ill do >what ever tell me what ever happens happens s > This task should be simple and require no authorized code. COBOL, PL1, and C/C== have the capability of writing JCL by reading the catalog (at worst an IDCAMS listing) emitting the appropriate JOB and EXEC images and using the data set names to create the input DD cards. The actual selection and extraction program should be written in the higher level (COBOL, PL1, C/C++) language for which record descriptions for the data on the files exist (I would hope in 2020 that it isn't assembler only). Having written programs to deal with the SMF30 records with variable position keys and extract CALL and COPY information from COBOL and DYL280 (now Vision Results) programs, I find it hard to believe that you are faced with a difficult task. If the language is COBOL, I have written code in COBOL to handle bit switches (snitched from a posting on comp.software.year-2000) and reference modification is simple. Clark Morris Clark Morris > >> On Oct 8, 2020, at 8:36 PM, Jeremy Nicoll >> wrote: >> >> ?On Thu, 8 Oct 2020, at 22:17, Joseph Reichman wrote: >>> There are number if restrictions in size of concatenation >> >> Yes, but suppose you can concatenate n datasets per dd? >> >> You read the list of datasetnames and then, n at a time, >> generate the right JCL. >> >> The point is, whatever the restrictions are, it cannot be hard >> to do it. >> >> >>> in addition there is CPU time step limit >> >> I don't understand that. >> >> If you have a legitimate business need to process all this data your >> systems programmers should provide you with a suitable job class. >> >> Indeed didn't someone else who IS an IRS sysprog reply a bit earlier >> saying that such classes DO exist? >> >> >>> I not working for a software co where I can go APF authorized and do >>> what ever I want >> >> Things may have changed but I don't recall APF authorisation having >> anything to do with time limits. >> >> Speak to your sysprogs. >> >> >> >> -- >> 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: dataset allocation
[Default] On 7 Oct 2020 10:03:05 -0700, in bit.listserv.ibm-main skol...@us.ibm.com (Sri h Kolusu) wrote: >> Yes at this point but since the file is variable >> I may need an exit to get the right spot at times to do a compare > >Joseph, > >You still haven't explained us as to what the real requirement is. DFSORT >can handle VB file with ease. Substring search will make sure you can >search anywhere within the record. > >> If these files are normally accessed by either COBOL or PL1, using a >> COBOL or Pl1 program in batch to do what you need to do will be faster >> to code. Both languages have reference modification so variably >> located fields can be easily dealt > >Clark, > >OP has different LRECL files and COBOL will not be able handle it, unless >you code all the files have a common LRECL > Since they are VB at worst you would have to code overrides to handle minimum LRECL for the program to handle them. Clark Morris > >Thanks, >Kolusu > >-- >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: dataset allocation
[Default] On 7 Oct 2020 08:50:04 -0700, in bit.listserv.ibm-main reichman...@gmail.com (Joseph Reichman) wrote: >Yes at this point but since the file is variable >I may need an exit to get the right spot at times to do a compare >There are 4,644 files an average of 240,000 records the file is VB the record >size can be 10,000 rough estimates > If these files are normally accessed by either COBOL or PL1, using a COBOL or Pl1 program in batch to do what you need to do will be faster to code. Both languages have reference modification so variably located fields can be easily dealt with (I have written programs in COBOL to process's SMF 30 records and to parse COBOL source statements for CALL and COPY usage). You can increase sequential performance by coding a BUFNO on the file such that a cylinder can bee read at a time. The advantage of COBOL is that the program(s) can bee easily used as templates for future job like this. Clark Morris >> On Oct 7, 2020, at 11:44 AM, Sri h Kolusu wrote: >> >> ? >>> >>>> There is a maximum of 5 min CPU time for job step >>>> In order to increase the TIOT the allocxx member had to be modified >> >> >> You don't have to change TIOT limit, we can cap the concatenation limit to >> whatever value we decide. Since you only have 5 mins of cpu time for each >> job, we probably can limit to 800-1000 dataset per job. >> >> So far you haven't explained as to what you are trying to do? Is it just >> picking records that match a condition? >> >> Thanks >> Kolusu >> >> -- >> 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: DFSort to pull the latest record date
[Default] On 25 Sep 2020 09:54:45 -0700, in bit.listserv.ibm-main ron5...@gmail.com (Ron Thomas) wrote: >Hello > >We are using DFSORT utility to extract the latest record for a store/item/po >and below is the sample file > >item_nbr| Store_nbr|Po_nbr|item_date|mode| >00604|9137|1100276393|2017-12-26|7|DSD | >00604|9137|1100278550|2018-01-09|6|DSD | > >Here we need to pull the 2'nd record to the Output as this is the latest date >. > >Could someone please let me know how to achieve the same Given the obscurity of the control statements (quick tell me what field is 1,4,CH) why not write the thing in a language that has access to the descriptions of the fields being used? We are not in the era of 22K DOS360 partitions, 100K MVT regions or 4 megabyte MVS regions anymore. PL1 and COBOL both generate fairly efficient code and when the tool becomes more than one off wonder, someone else can pick up the program and have a fighting chance of understanding what was being done. Clark Morris > >Regards >Ron T > >-- >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
BOF on COBOL and the systems programmer at SHARE
I am giving a BOF on COBOL and the systems programmer on Thursday, September 24 in the last session period - 16:15 Eastern time zone, 15:15 Central time zone, 14:15, Mountain time zone, 13:15 Pacific time, 17:15 Atlantic time zone in Canada and 17:45 in Newfoundland. There will be a 10 minute introduction (I timed it). It covers items in the COBOL standard not in Enterprise COBOL that might be of use to your shop, facilities in Enterprise COBOL that your shop may have overlooked, caution on setting defaults, and why standards should be reviewed with each new release. The rest of the session will be devoted to whatever the attendees want to discuss and explore. I have used COBOL to get information from SMF records because it was easier than assembler and my shop didn't have SAS. I have been responsible for review and recommendation of COBOl and LE defaults in 2 different shops. I was active in SHARE starting in 1977 through 2002. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
MVT 21.8 on a 4341 was Re: Architectural Level Sets
[Default] On 9 Sep 2020 16:16:01 -0700, in bit.listserv.ibm-main dspiegel...@hotmail.com (David Spiegel) wrote: >Hi Clark, >Did you run MVS on a 4341? >If yes, which version? Headquarters normally did our MVT sysgens for us so this was the first MVT sysgen I had done. After checking with Paul Dalman of Army Records, Rick Steffee of Naval Intelligence and Brian Scott of Volume Shoe, all of who had presented at a SHARE session on the topic, I genned 21.8 final as for a 370/158. We had lost our mod 65 due to a roof leak on Sunday so I made the phone calls on Monday just in case. Monday IBM was going to fix it. Tuesday was a different story and we got the system up by Wednesday morning. My boss and a fellow systems programmer had to learn about Unit Control Words so we could use our Comten. All in all an interesting time. Clark Morris > >Thanks and regards, >David > >On 2020-09-09 19:12, Clark Morris wrote: >> [Default] On 9 Sep 2020 14:47:15 -0700, in bit.listserv.ibm-main >> sme...@gmu.edu (Seymour J Metz) wrote: >> >>> In XA mode the problem is the SIO instruction. DOS.360, OS/360, OS/VS, etc. >>> don't support SSCH. Does OS/360 need BC when you sysgen for S/370? I'm >>> certain;ly not aware of such a dependency in OS/VS or VM. >> MVT ran on a 4341 generated as a 370/158 in my shop while we were >> upgrading to MVS. >> >> Clark Morris >> >> -- >> 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: Architectural Level Sets
[Default] On 9 Sep 2020 14:47:15 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >In XA mode the problem is the SIO instruction. DOS.360, OS/360, OS/VS, etc. >don't support SSCH. Does OS/360 need BC when you sysgen for S/370? I'm >certain;ly not aware of such a dependency in OS/VS or VM. MVT ran on a 4341 generated as a 370/158 in my shop while we were upgrading to MVS. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Architectural Level Sets
[Default] On 4 Sep 2020 03:50:04 -0700, in bit.listserv.ibm-main
greg.pr...@optusnet.com.au (Greg Price) wrote:
>Hi - regarding several points in this thread...
>
>What I think I know:
>
>MVS 3.8 had:
>- MF/1 (component prefix IRB) writing the SMF type 7n records
>- physical swapping only
>- sequential SMF data sets ("TCLOSE" anyone?)
>
>SE1 and SE2 were free (as in zero dollars) but licensed.
>
>MVS/SE2 had
>- RMF (component prefix ERB) writing the SMF type 7n records
>- physical and logical (at least for swap types TI and TO)
>- VSAM SMF data sets (flagged by the high-order (or sign bit) of CVTSMCA
>being set)
>
>Does anyone know if any of those things were delivered in SE1 (which I
>never saw AFAIK)?
>
>Where I worked ran a 370/158 MP (6MB real) on MVS/SE2 3.8H (1983?)
>- they also got an Amdahl V7B->V7A->V7->V8 ("got all cylinders firing")
>
>I was very surprised when MVS/SP 1.2 ran on the 158 because I would have
>thought that DAS required extra hardware that was not thought of when
>the 158 was first designed and built.
>
>When I heard of the 4300 series, I heard of:
>4331 - lower end
>4341 - a bit more "oompf"
It could and did run MVT rel. 21.8. We did it at my shop with phone
advice from Rick Steffee (sp.) pf Naval Intelligence, Brian Scott of
Volume Shoe and Paul Dalman from Army Records.
>both came in Group I or Group II - don't know what the difference was.
>
>A 4331 could not run MVS.
>
>The 4300 series were geared toward the VM/VSE crowd.
>
>Was there a 4361 ?
Yes, it was an follow-on to the 4331.
Clark Morris
>
>In 1987 I worked on an MVS/XA system (SP2.1 -> SP2.2) on a 4381.
>
>
>I'd welcome any corrections to - or even confirmations of - any of the
>above factoids.
>
>
>And also...
>
>Is not one of the main points of an ALS is that the the BCP (et al)
>coders can assume that the newer instructions in place at that level can
>be freely used within the object code of their components?
>
>Cheers,
>Greg P.
>
>--
>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
4342 and 4381 ran MVS was Re: Architectural Level Sets
[Default] On 1 Sep 2020 14:26:32 -0700, in bit.listserv.ibm-main mike.a.sch...@gmail.com (Mike Schwab) wrote: >Well, XA+ machines only supported 4K pages / 1M segments and not 2K >pages / 64K segments. Then DAS and Access register additions. The >43xx series only supported a single virtual address space, like >DOS/VSE. 3090s were the only processors to support Vector >instructions, and op codes were re-used in z series. The 4341 and 4381 could and did run MVS. I was responsible for MVs on them at my site. Clark Morris > >On Tue, Sep 1, 2020 at 4:20 PM Tony Thigpen wrote: >> >> I was thinking more along the lines of things that prevented earlier >> operating systems from even IPLing on newer boxes. Such as z13 is the >> last processor to have ESA/390 mode. I also have it in my head that at >> some point there were changes to the page size and virtual storage >> tables that caused havoc. >> >> Tony Thigpen >> >> Seymour J Metz wrote on 9/1/20 3:30 PM: >> > Typically the new features reqiured by a level set were added over several >> > generations, and each generation added more than one feature. >> > >> > >> > -- >> > Shmuel (Seymour J.) Metz >> > http://mason.gmu.edu/~smetz3 >> > >> > >> > >> > From: IBM Mainframe Discussion List on behalf >> > of Tony Thigpen >> > Sent: Tuesday, September 1, 2020 3:25 PM >> > To: IBM-MAIN@LISTSERV.UA.EDU >> > Subject: Architectural Level Sets >> > >> > IBM has had several Architectural Level Set points where there were >> > significant changes to the CPU that prevented earlier operating systems >> > from running on them. >> > >> > What CPU's were involved with each level, and what was the real >> > underlying item changed on the CPU that forced a new level? (Let's keep >> > it limited to z990 and newer.) >> > >> > >> > Tony Thigpen >> > >> > -- >> > For IBM-MAIN subscribe / signoff / archive access instructions, >> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > >> > -- >> > For IBM-MAIN subscribe / signoff / archive access instructions, >> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Simple VSAM question on sizing INDEX component
[Default] On 30 Aug 2020 15:12:07 -0700, in bit.listserv.ibm-main stars...@mindspring.com (Lizette Koehler) wrote: >List - > > > >I have a VSAM Dataset that has grown over the years. When it was set up - >the INDEX space was left to default > One other thing to check for in addition to the other recommendations given is whether or not the file should have grown this large. I ran into a case in one shop I was at where records were getting on the file but because of a coding error only certain ones were getting updated and removed. I was a systems programmer who went back into applications and was actually tracking down why a run time had increased. Clark Morris > >I am wondering if it makes sense to override the Track Allocation and put it >in Cylinders. > > > >We are noticing a little bit of an increase in run time during reorg. I was >wondering if this might be due to the data set having 3.4GB now. This file >is EA/EF so it can grow > > > >Over 4500 Cylinders on the Data > >And the index is using tracks 2 pri and 11 sec - size is now 2.4 MB > > > > > >During reorg we offload records to an archive then reload the current data >back in. > > > >This may be something I cannot improve on, just thought I would see if there >are any insights I am missing. > > > >Process: >Offload the data to a temp file > >Archive records older than 2 weeks > >Del/Def VSAM dataset > >Reload current records to VSAM dataset > > > >This runs daily > > >Thank you > > > >Lizette > > >-- >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: Anyone Using MVS Bulk Data Transfer (File-to-File)?
[Default] On 20 Aug 2020 13:31:43 -0700, in bit.listserv.ibm-main edja...@phoenixsoftware.com (Ed Jaffe) wrote: >On 8/20/2020 1:14 PM, Clark Morris wrote: >> >> Any shop using SNA-NJE on JES3 needs it. Since JES2 didn't require it >> for SNA-NJE, my single instance shop converted to JES2 so we saved by >> both not having to pay for BDT but also JES2 was cheaper. > >Good observation! > >I didn't specify whether I was referring to the BDT SNA/NJE function or >the BDT File-to-File function. I think that IBM dead ended and stopped support of the File-to-file and all other non-JES3 related functions at least 18 years ago. Clark Morris > >I was thinking of the latter... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Anyone Using MVS Bulk Data Transfer?
[Default] On 20 Aug 2020 09:02:35 -0700, in bit.listserv.ibm-main edja...@phoenixsoftware.com (Ed Jaffe) wrote: >Came across someone using this product and wondered how popular it was. > Any shop using SNA-NJE on JES3 needs it. Since JES2 didn't require it for SNA-NJE, my single instance shop converted to JES2 so we saved by both not having to pay for BDT but also JES2 was cheaper. I modified the EXIT from American Natural Resources and some other JES and MVS exits to keep the system looking somewhat like JES3 to the programmers. The concurrent installation of CA-DISPATCH - a report manager also helped. The conversion to JES2 forced getting all production jobs converted to use CA-DISPATCH before the JES2 cutover so the projects fed each other. Clark Morris >Has it been replaced by more-recent z/OS functionality? Or does it >remain the only way to do certain things? > >Thanks, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Keeping TSO users our of CICS
[Default] On 27 Jul 2020 13:40:48 -0700, in bit.listserv.ibm-main stars...@mindspring.com (Lizette Koehler) wrote: >First if you have not done so, you might want to join the CICS or RACF >Lists. While I am at least 20 years out of date, it used to be that someone had to be set up in each CICS region they were allowed to access. So far as I know access to TSO does not automatically get you access to CICS and having access to CICS test does not mean access to CICS production or even CICS test for a different region. Clark Morris > >I think the IRR profiles can avoid the use of SPECIAL and OPERATIONS, but >you would need to research that > > >I think the RACF List may be more helpful > >CICS http://www.listserv.uga.edu/archives/cics-l.html >RACF http://www.listserv.uga.edu/archives/racf-l.html > > >Next I think here are IRR profiles that can be used to reset passwords. I >am not very familiar with it, I think this > >https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1 >.icha700/icha700_Steps_for_delegating_the_authority_to_reset_passwords_by_gr >oup_tree.htm > > >Steps for delegating the authority to reset passwords by group tree > >Before you begin: > >Make sure the ALTUSER command issuer does not have similar access to the >IRR.PASSWORD.RESET resource in the FACILITY class. >Ensure that list-of-groups-checking (SETROPTS GRPLIST) is enabled. > >Perform the following steps to limit the authority of a general user or >group to resume user IDs and reset passwords and password phrases based on >the scope of a group tree. > >Define the following generic profiles in the FACILITY class, if not >already defined. Doing so ensures that an existing generic profile does not >inadvertently prevent you from successfully limiting this authority. >Example: > >RDEFINE FACILITY IRR.PASSWORD.RESET.** UACC(NONE) >RDEFINE FACILITY IRR.PWRESET.** UACC(NONE) >RDEFINE FACILITY IRR.PWRESET.EXCLUDE.** UACC(READ) > >If you use UPDATE or CONTROL access for any IRR.PWRESET profile, as >described in Table 1, specify the higher level (UPDATE or CONTROL) with the >UACC operand for the IRR.PWRESET.EXCLUDE.** profile instead of the >UACC(READ) option shown in this example. >Define a profile to protect the IRR.PWRESET.TREE.owner resource in the >FACILITY class, where owner is the group that is at the top of a group tree. >Example: > >RDEFINE FACILITY IRR.PWRESET.TREE.GROUP1 UACC(NONE) > AUDIT(FAILURES(NONE) SUCCESSES(READ)) > > >https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1 >.icha700/icha700_Steps_for_delegating_the_authority_to_reset_the_password_fo >r_any_user.htm > >Steps for delegating the authority to reset the password for any user >Perform the following steps to authorize a general user or group to use the >ALTUSER command to resume a revoked user or reset a user's password or >password phrase. > >Define a profile to protect the IRR.PASSWORD.RESET resource in the >FACILITY class. >Example: > >RDEFINE FACILITY IRR.PASSWORD.RESET UACC(NONE) > AUDIT(FAILURES(NONE) SUCCESSES(READ)) > >__ >Authorize the general users or groups. >Example: > >PERMIT IRR.PASSWORD.RESET CLASS(FACILITY) ID(HELPDESK USER19) >ACCESS(READ) > >See Levels of authority for restrictions and details about authority >based on the access level to IRR.PASSWORD.RESET. > >__ >Activate the FACILITY class if not already active. >Example: > >SETROPTS CLASSACT(FACILITY) > >If the FACILITY class is already active and RACLISTed, refresh the >FACILITY class profiles. > >SETROPTS RACLIST(FACILITY) REFRESH > >__ > >You have now authorized a general user or group to use the ALTUSER command >to resume the user ID or reset the password or password phrase for any user, >excluding protected users and users with the SPECIAL, OPERATION, or AUDITOR >attribute. > > >-Original Message- >From: IBM Mainframe Discussion List On Behalf Of >McCabe, Ron >Sent: Monday, July 27, 2020 1:32 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Keeping TSO users our of CICS > >Hello IBM Listers, > >Got an interesting problem that I would like to know how we can avoid. Our >Help Desk users TSO accounts have the SPECIAL ATTRIBUTE so they can reset >passwords and define new users. These TSO accounts are not defined to CICS >but every once in awhile one of them will try to l
Implementation of COBOL non-standard rounding
Currently in IBM Enterprise COBOL the only rounding is round half away from zero (5.5 becomes 6, -5.5 becomes -6). I understand than various organizations use different rounding rules based on policy and/or legal requirements in some or all computations involving rounding. These would include round half to nearest even (5.5 becomes 6, 4.5 becomes 4. How do organizations handle the non-standard rounding in current COBOL programs? in-line code with each computation? PERFORM of a common subroutine copied into the program? CALL to a separate COBOL subroutine? CALL to a routine in another language? If the 2014 COBOL Standard additional rounding options included the ones your organization uses, would your organization modify code over time to take advantage of the software and hardware support for them, assuming that they would deliver identical results? Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
COBOL at Virtual Share
If I join the virtual SHARE I would like to set up a BOF to discuss the new Binary usages (they would obviate truncation problems and picture usage discrepancy), Boolean capabilities (bit manipulation and testing), IEEE floating point usages and new decimal rounding operations such as round half to nearest even. The previous items are in the 2002 and 2014 standards. This would focus on whether we believe an installation would use them if they existed and how they could be sold to the various level of management. Some may be 40 years too late. Would anybody be interested? Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OOBOL and English was Re: Still COBOL After All These Years?
[Default] On 16 Jul 2020 20:01:25 -0700, in bit.listserv.ibm-main wayn...@gmail.com (Wayne Bickerdike) wrote: >COBOL fails at MOVE. It's a COPY. Maybe they should have said REPLICATE, >since COPY was already taken. So, not good English. I agree. COPY should have been INCLUDE and MOVE should have been COPY. There are probably other examples that I can't think of at the moment. Clark Morris > >On Fri, Jul 17, 2020 at 12:46 PM Tony Thigpen wrote: > >> I agree with Clark. >> >> In addition, even the best language can have it's best features ignored >> by programmers so that others can claim it's the language's fault. >> >> I have seen both REXX and C code that was totally unreadable due to the >> programmer putting 24 nested functions in one statement. I have seen >> COBOL code that is unreadable because the programmer used cryptic >> variable names are very complex IF comparisons. I even saw one COBOL >> program where the variables were all in Spanish in a shop in North >> Alabama where there was only one programmer that spoke Spanish within >> 100 miles. Totally unreadable by the guy that followed him (me). >> >> Don't blame the language. Blame the management that allowed programmers >> to write code that was not readable by the next guy. >> >> I used to work for a large software development firm that had strict >> standards. This was before even dial-up. Most new programmers fussed >> about the programming standards. Until, they got a support call at 3am >> and had to debug a program over the phone with the customer reading the >> COBOL source to them. Taking a little longer to code, and typing a >> little more, cost very little but added a lot of ease to the back end >> when it came to support. >> >> Tony Thigpen >> >> Clark Morris wrote on 7/16/20 10:16 PM: >> > [Default] On 16 Jul 2020 10:34:40 -0700, in bit.listserv.ibm-main >> > sme...@gmu.edu (Seymour J Metz) wrote: >> > >> >> The claim that COBOL is English like is every bit as bogus as the claim >> that rewriting existing COBOL applications in another language will >> magically fix problems of underfunding, understaffing and general >> mismanagement. >> > >> > Looking at some of the comment I have seen in Assembler code including >> > my own, COBOL code is close to the syntax of those comments. >> > >> > Clark Morris >> >> >> >> BTW, when the language du jour is out of fashion, will they want to >> rewrite the application again, with the same pretext? And will they ensure >> that this time they have adequate documentation and adequate configuration >> control? >> > >> > -- >> > 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
OOBOL and English was Re: Still COBOL After All These Years?
[Default] On 16 Jul 2020 10:34:40 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >The claim that COBOL is English like is every bit as bogus as the claim that >rewriting existing COBOL applications in another language will magically fix >problems of underfunding, understaffing and general mismanagement. Looking at some of the comment I have seen in Assembler code including my own, COBOL code is close to the syntax of those comments. Clark Morris > >BTW, when the language du jour is out of fashion, will they want to rewrite >the application again, with the same pretext? And will they ensure that this >time they have adequate documentation and adequate configuration control? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Application necessities was Re: Still COBOL After All These Years?
[Default] On 16 Jul 2020 10:34:40 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >The claim that COBOL is English like is every bit as bogus as the claim that >rewriting existing COBOL applications in another language will magically fix >problems of underfunding, understaffing and general mismanagement. One thing that could help is changing many shops that are still coding as if it were COBOL 74 (COBOL/VS) even if they are on the latest Enterprise COBOL. > >BTW, when the language du jour is out of fashion, will they want to rewrite >the application again, with the same pretext? And will they ensure that this >time they have adequate documentation and adequate configuration control? And will they have an adequate test mechanism for both online and batch? The hardest part of my job where I worked was getting a coordinated set of test data that I could use as a base. I also have come to the conclusion that the way systems should be developed is the helps and user documentation would come before code and form the specifications for the system. In some of the newer development methodologies, maybe that could be concurrent. All fixes would be either changes to the code to match the help and documentation or the help and documentation to match the code. Technical writers should be a part of the development teams. A large portion of the coding community including me is poor at writing. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SuperWylbur Users
[Default] On 5 Jul 2020 04:13:31 -0700, in bit.listserv.ibm-main gil...@gmail.com (John S. Giltner, Jr.) wrote: >Unfortunately SSI is going out of business and is dropping all support Dec. >31, 2020 and is not guaranteeing that SuperWylbur will work with 2.4 or beyond. Is Super-Wylbur distributed in source format as opposed to load modules? Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
COBOL growing? was Re: Mainframe co-op
[Default] On 3 Jul 2020 12:15:16 -0700, in bit.listserv.ibm-main ste...@copper.net (ste...@copper.net) wrote: >> snip > >Meanwhile, you must have HLASM and probably want to have the toolkit >(separately chargeable as I understand it). You will need all the compilers >being used COBOL, PL/1, c/C++, etc.. Can you get them under a development >license? > >snip > >If I could (and because of who I work for, and for those of you who think I >work for Humana, I did at one time, but things change...), I would go to a >University or college and propose this: A Mainframe Academic center. And I >would tie that with somehow teaching COBOL (it ain't dead, and it is still >growing), and possibly CICS & DB2. If IBM still does an academic licensing >thing, then this is the cheapest way to go that I am aware of. And if you can >get the school to do an open semester year tuition allowing one to do self >directed studies > As someone who still follows comp.lang.cobol and vaguely keeps track of the ob market, I am skeptical about the growth of COBOL especially for new projects. It would seem more productive to have customizable packages that run on non-mainframe (z and other) systems which are at the OS level native UTF8 or UTF16. I would like to be proven wrong. Incidentally with the 2002 and 2014 language enhancements COBOL is a good tool for dealing with SMF records. Clark Morris >Believe me, with all the outsourced contractors I deal with who have degrees >in IT Theory and absolutely no PROGRAMMING experience outside of some OO >language, I could see this being something that might get some traction since >with COVID-19 we just found out that we can do classes virtually to anywhere >(those of us who have been working from Home for decades already knew that). > >And you might get certain companies to throw in their tools, such as z/XDC for >a low price. > >Ok, maybe more than 2 cents, but these are my observations having done some of >this before Outsourcing organizations became Cloud companies. > >THE HEADACHE not yet mentioned is, one may not be able to get support for this >system. So one may have to wait until a production machine somewhere hits your >problem to get an APAR/PTF. > > >Regards, >Steve Thompson > > >--- charl...@mcn.org wrote: > >From: Charles Mills >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: [IBM-MAIN] Mainframe co-op >Date: Fri, 3 Jul 2020 11:41:52 -0700 > >A model to look at might be the IBM Innovation Center, Dallas. > >The price is higher than what I picture as your target: $550/month and up >IIRC. You get two dedicated VM virtual machines: one that runs CMS and that >you use as a console. You can do limited console automation with Rexx. And one >on which you IPL z/OS. The z/OS -- any current version that you want -- runs >from shared read-only DASD that IBM maintains: PTFs and so forth are IBM's >problem. You get just about every IBM product that you could possibly want -- >again, read-only DASD, with IBM doing the PTFs. > >For $550 IIRC you get everything you "need." More DASD, lots and lots of CPU >cycles, etc. entail an upcharge. > >You "own" the configuration. If you want to muck up SYS1.PARMLIB so that z/OS >will not IPL, it's your gun, your bullet, your foot. I have never done it, so >I don't know, but I would assume IBM has some way of getting you back running. >You "own" RACF. You can have as many userid's as you care to define. If you >want to experiment with permissions in any way you choose, go at it. IBM >provides very limited support: (1) if you need help you can ask by e-mail: >sometimes you get great help, sometimes not; (2) no PMR support. You are not a >z/OS licensee and thus not entitled to PMR support. I would assume that if you >had some fatal problem you could go route (1) and get IBM to address it >somehow: I have no experience. > >It is a good option for an individual or small company just a little above >your intended price point. You have to a certain extent the best of both >worlds: you have a z/OS that you can do with as you wish just as if you owned >the box; and you have IBM doing the z/OS PTFs and basic installs and volume >backups and so forth that I at least don't care to do. You do not have to do >any initial install: your z/OS will IPL on day one. > >It is current hardware. I believe we are currently running on a z14. > >There are also offerings for VM, VSE and Linux IIRC but I am not familiar with >them. > >You cannot do "production." You can let customers on for demos, but that is >it. (Speaking from memory; I am not an IBM attorney.) You have to be a >"software vendor" de
When did .net become obsolete? was Re: z/OS use of "legacy" programming languages
[Default] On 2 Jul 2020 02:13:34 -0700, in bit.listserv.ibm-main r.skoru...@bremultibank.com.pl (R.S.) wrote: >> snip > >BTW: As a mainframe bigot I sometimes am forced to explain why so old >things are still in use. Yes, z14 or z15 is veery old. As old as >z/OS 2.4, or DB2. It is hard job, because usually nobody want to hear >answers, but one of my favorite is the wheel. Wheel is quite old idea, >but still in common use. They say M$ introduced a car without wheels or >the the wheels are enhanced - square... >Last, but not least: some 20 years old COBOL code is not obsoleted by >changes in the OS/compiler/whatever, but code on Windows *had* to be >rewritten several times during this period. Dot net? It was so modern >just few years ago and now is obsolete. Note: that means programming >effort just to upgrade system, without any application (business logic) >changes. When did dot net become obsolete? Versions earlier than 3 are no longer supported but when I did a search for dot net both the Microsoft pointers and the wiki article seemed to show it is very much alive and is now open source. The original implantation was well before 2010 and was starting to be open sourced before then. Clark Morris Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS use of "legacy" programming languages
[Default] On 1 Jul 2020 21:39:05 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >Do you mean only that IBM has changed the underlying hardware used to >implement what they called Machine Interface (MI) on the S/38, or do you mean >that they have changed the MI itself? I don't know enough about the boxes to say. I just was fairly certain that the hardware instruction set for the s38/AS400 differed from IBM i. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS use of "legacy" programming languages
[Default] On 1 Jul 2020 14:43:51 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >Comfort isn't the only issue. When they change the law such that the code no >longer complies, then you have to bite the bullet and update it? Lost the >source code? There could be legal consequences. YMMV. > >There used to be an operating system with no support for running from an >object deck; the compilers were fast enough that it wasn't an issue. I >sometimes think they had the right idea. That reads like MUMPS or AS400/IBM-i. I know AS400/IBM-i have changed instruction sets. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Virtual SHARE Ageenda
[Default] On 29 Jun 2020 18:05:01 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >Re FBA, they did it for other systems, and TSS/360 used page formatted volumes >for everything except compatibility volumes, so from a technical perspective >it's a no brainer, although direct use of SCSI DASD might make more sense >these days. Politically, it's a thorny issue. I'd love to see them extend VSAM >to the level of TSS while they're at it, e.g., VIPAM. What is the logical difference between VPAM (found it in a TSS360 description) and PDSE except PDSE is an add-on (my opinion of the decision maker who decreed that PDSE or at least a read-only subset didn't need to be available for SYS1.PARMLIB, SYS1.NUCLEUS and SYS1.LPALIB is complete contempt)? Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Virtual SHARE Ageenda
The virtual SHARE in August will cost only 199 USD for members, 399 USD for non-members. There will obviously be no travel expenses if you have access to high enough speed Internet. There are opportunities for Birds Of a Feather sessions. If I sign up, I might try to set up a BOF session on COBOL 2014, some of the very useful features and whether they are 20 - 40 years too late because organizations have already implemented work-arounds and won't revisit the code? I also am interested in discussing whether making the effort to have z/OS handle FBA devices for FBA data sets (all VSAM, PDSEs, page data sets, etc.) would be worthwhile and creating FBA equivalents of SYS1.NUCLEUS (combine it with the IPL text?) SPOOL etc.? The schedule which gives the dates and shows the slots for BOF sessions. https://event.share.org/schedule The actual session agenda which even adjusts the times to your time zone (mine is Atlantic Daylight Time). If I was still a working systems programmer, I would definitely sign up. https://virtual.share.org/agenda#/?limit=20=item,oLShgQgAGAsAB9xbo,oLShgQgAGAsAB9xbo,405,120=120[0]=startsAt[0]=1 Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
FACT was Re: COBOL and C
[Default] On 27 Apr 2020 04:13:21 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >> And CPL before that (born in 1963). Yes, COBOL has roots in FLOW-MATIC >(mostly, with a light dusting of COM-TRAN), > >"FACT is fiction"? (Honeywell) The first full-time job I had coming out of school in 1961 was Equitable Life Assurance Society where they were installing a Honeywell 800 and planning to use FACT. The 800 had 8 processors and set of registers, 48 bit words and both decimal and binary arithmetic. A FACT program would use 3 of those sets as I recall. and was segmented at the paragraph level. It had a number of advanced features, some of which I would like in today's COBOL. Unfortunately it probably required a machine that had 10 times the memory and fast disk drives instead of one that was basically a tape drive machine (think rolling in code from tape repeatedly. My Netbook would be far better suited to it than the H800 as would a 4341. I downloaded a copy of the FACT manual before making this post to refresh my memory. Clark Morris > >Did the CODASYL SRC committee get anything from 9PAC? JOVIAL? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: dfdss equivalent to fdr map
[Default] On 20 Jun 2020 19:33:23 -0700, in bit.listserv.ibm-main haresystemssupp...@comcast.net (Tim Hare) wrote: >Question: does it really matter with a volume that's a virtual thing >implemented on a RAID array? Number of extents still would matter. Also if the data set was allocated in tracks rather than cylinders there could bee more end of extent checking. Clark Morris > >-- >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
ALTER preceded structured programming and hostile to it was Re: Goto Statements AND COBOL OPTIMIZATION
[Default] On 11 Jun 2020 16:17:47 -0700, in bit.listserv.ibm-main rreyno...@cix.co.uk (Rupert Reynolds) wrote: >I lost faith COBOL and finallly became a PL/1 biggot when I was told that >ALTER GOTO was introduced to help support structured programmng :-) As someone who made extensive use ALTER x-exit TO y, GO TO x because of PERFORM code generation on DOS360 and small partitions, I guarantee you the construct preceded structured programming and was less than friendly to maintenance programmers. I rewrote more than one of my programs when partitions grew to be structured and eliminate ALTER statements. Clark Morris > >Rupert > >On Thu, Jun 11, 2020, 01:07 Tom Ross wrote: > >> >The addition of EXIT PARAGRAPH >> >and EXIT SECTION have eliminated most of the reasons for use of GO TO >> >in COBOL. I would be interested in any corrections to my >> >understanding by those responsible for the COBOL compiler. =20 >> >> I partially agree, Clark, but what really made it easy to get rid of GOTOs >> in COBOL (if you wanted to) was EXIT PERFORM and especially EXIT PERFORM >> CYCLE! >> These were added to the Standard with COBOL 2014 and implemented by IBM in >> Enterprise >> COBOL for z/OS V5.2 >> >> Cheers, >> TomR >> COBOL is the Language of the Future! << >> >> -- >> 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: Goto Statements AND COBOL OPTIMIZATION
[Default] On 10 Jun 2020 17:14:25 -0700, in bit.listserv.ibm-main tmr...@stlvm20.vnet.ibm.com (Tom Ross) wrote: >>The addition of EXIT PARAGRAPH >>and EXIT SECTION have eliminated most of the reasons for use of GO TO >>in COBOL. I would be interested in any corrections to my >>understanding by those responsible for the COBOL compiler. =20 > >I partially agree, Clark, but what really made it easy to get rid of GOTOs >in COBOL (if you wanted to) was EXIT PERFORM and especially EXIT PERFORM CYCLE! >These were added to the Standard with COBOL 2014 and implemented by IBM in >Enterprise >COBOL for z/OS V5.2 I agree but the main question I was raising is whether if I have GO TO blow-up-paragraph where blow-up-paragraph is the last paragraph which has a CALL "ILBOABN0" or its LE equivalent followed by GOBACK as the last two statements will that disrupt PERFORM optimization? Starting with VS COBOL II release 4 I have PERFORMed blow-up-paragrraph to make sure that my program is fully optimized. Clark Morris > >Cheers, >TomR >> COBOL is the Language of the Future! << > >-- >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
Don't Hire Chuck Norris was Re: restart GIMSMP in unpack step
[Default] On 10 Jun 2020 07:43:41 -0700, in bit.listserv.ibm-main ku...@us.ibm.com (Kurt Quackenbush) wrote: >> snip >Kurt Quackenbush -- IBM, SMP/E Development >Chuck Norris never uses CHECK when he applies PTFs. Don't Hire Chuck Norris for any systems work. Clark Morris > >-- >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: Goto Statements AND COBOL OPTIMIZATION (was: COBOL Question)
[Default] On 8 Jun 2020 01:55:52 -0700, in bit.listserv.ibm-main dcrayf...@gmail.com (David Crayford) wrote: >I learned JSP back in the early 90's. It was popular in the UK (Jackson >was British) and most large mainframe companies adopted it. It was good. >There was even tooling that >could create code from charts. > >Dijkstra's paper is one of the most controversial CS papers ever >written. It was written before structured programming took off and >programming languages >like FORTRAN and COBOL were not well structured at the time. >Unfortunately, people drank the kool-aid and a whole generation of >programmers were brain-washed by dogma >that goto is inherently evil. I see code all the time that eschews goto >for error handling and the alternative is never better. In fact, it's >always crap! It's either deeply nested if-logic or extra status >flag checks. For languages that support try/finally, use groups, RAII >etc the problem doesn't exist but that's certainly not the case from >almost all mainstream languages that run on z/OS >other than Java and C++. > My avoidance of GO TO in COBOL is based on my understanding of IBM COBOL compiler optimization and not a computer theology that says all GO TO is bad. In the case of error clean up and blow up paragraphs, from a clarity point of view I would prefer to GO TO them but I believe this could adversely affect optimization. While I can't speak for other languages, VS COBOL 2.4 and later optimizations Enterprise COBOL 5.2 do PERFORM optimization where Paragraphs that can only be PERFORMed will cause a simplified generation of code for the related PERFORMs. In some cases the Paragraph is moved inline to replace the PERFORM statement which can bee a performance advantage for caching. I don't believe that PERFORM ... THRU statements are eligible for this optimization. I have avoided GO TO statements and even used PERFORM to execute the error abort Paragraphs accepting the warning message to make certain the optimization could take place. This is because in COBOL the same paragraph could be reached by PERFORM x, PERFORM x THRU exit-x1, PERFORM x THRU exit-x2 and GO TO x. The addition of EXIT PARAGRAPH and EXIT SECTION have eliminated most of the reasons for use of GO TO in COBOL. I would be interested in any corrections to my understanding by those responsible for the COBOL compiler. Clark Morris > >On 2020-06-08 4:28 PM, Wayne Bickerdike wrote: >> Dijkstra wrote his missive around 1968. Knuth made a meal of it and after >> reading his paper which was published 5 years later, it was too hard a read. >> >> Around the same time Michael Jackson was distilling this information and >> produced his structured programming book "Principles of Program Design". I >> still have a copy and generally will approach program design using the same >> tried and tested techniques. At IBM in 1978 we had an advocate for the same >> methods, Tony Droar. Unfortunately, a lot of this good work seemed to miss >> a lot of organisations. Some places I worked in the 80's wouldn't allow a >> sort to make a program easier to write. >> >> Jackson explained go to was essential, particularly when performing >> validationposit.admitquit. I've seen a Jackson structure design >> turned into a flowchart and the structure is lost. Flowcharts encouraged >> the use of GO TO. >> >> On Mon, Jun 8, 2020 at 4:45 PM David Crayford wrote: >> >>> On 2020-06-07 10:48 PM, Paul Gilmartin wrote: >>>>> I consider the out of line PERFORM to be far more dangerous. I have a >>> similar issue with REXX; it does not have lexical scope, and you can fall >>> into a procedure. >>>> A noteworthy 1976 paper (behind a paywall): >>>> Software malpractice a distasteful experience >>>> https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380060303 >>>> >>>> ... describes the pitfall set by a (too) clever programmer's relying on >>>> optimization by falling into procedures. >>>> >>>> In the day, I read it free in the University library. >>> I'm sure that paper is an interesting read from a historical >>> perspective. It's referenced in Code Complete along with another >>> reference to Frank Rubin's letter to the ACM (March 1987) >>> in which he asserts that goto-less programming has cost business >>> "hundreds of millions of dollars". >>> >>> The original context of the "goto considered harmful" is lost on the >>> younger generation, as at the time there were large swaths of developers >>> who were trained before structured programming took off. >>> There a
Re: Goto Statements (was: COBOL Question)
[Default] On 7 Jun 2020 03:33:44 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >I generally get by with control structures like case (select/when), >if/elsif/when, iterate and leave, but I unashamedly use GOTO, when it is the >cleanest way to do something; I refuse to avoid a useful construct just >because it is not politically correct. In the case of COBOL, I consider the >out of line PERFORM to be far more dangerous. I have a similar issue with >REXX; it does not have lexical scope, and you can fall into a procedure. With any supported IBM COBOL, it can and should be written such that there are no fall throughs and without PERFORM ... THRU ... statements. By use of only PERFORM statements (without THRU) code movement is possible such that PERFORMED paragraphs can be moved inline which can be important in this era of cache and instruction look ahead. In order to maintain the ability for the compiler to do code optimizing I have coded PERFORMs of catastrophe paragraphs which have terminating STOP RUN, GOBACK or calls to an ABEND routine. Code which was optimal under OS/VS COBOL (1974 standard) became poor under VS COBOL 2.4 and later (1985 standard and later). As someone who coded programs ALTER xxx TO yyy instead of PERFORM to save 16 bytes in order to fit into a 16K DOS 360 background partition or 6K DOS 360 foreground partition, this represents a drastic change in philosophy. In the late 1980s I drastically rewrote a program to substantially reduce both CPU and run time in the late 1980s or early 1990s in the OS/VS COBOL available to me. ALL PERFORM xxx VARYING statements were eliminated and PERFORM xxx THRU xxx-EXIT statements were used where GO TO xxx and GO TO xxx-EXIT statements were used to do the iteration of the loop and the exiting of the loop. I submitted an article to the NAASPA magazine (the name escapes me at the moment) regarding all of the optimizations which was published. I did put in the caveat that the VS COBOL II compiler would make some of those optimizations counter-productive. Indeed to accomplish the same goal the rewrite would have had to have been substantially different for VS COBOL 2.4 and later. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
[Default] On 6 Jun 2020 12:43:09 -0700, in bit.listserv.ibm-main joemon...@gmail.com (Joe Monk) wrote: >Granted its been awhile since ive done application code, but if you >dont end-if they become a nested condition, which I dont think was the >original intent. A conditional statement in COBOL is terminated either by a period or an END-xx statement. The arithmetic statements become conditional if there is an "ON SIZE ERROR" clause so that there are END-ADD, END-SUBTRACT, END-COMPUTE, etc. statements. I-O statements such as READ and WRITE become conditional if there are "AT END", INVALID KEY" or similar statements so there are END-READ and END-WRITE statements. Clark Morris > >Joe > >On Sat, Jun 6, 2020 at 1:40 PM Paul Gilmartin < >000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > >> On Sat, 6 Jun 2020 15:28:57 -0300, Clark Morris wrote: >> >> >On 6 Jun 2020 10:53:44 -0700, (Bob Bridges) wrote: >> > >> >>Oh, you need an END-IF even for a single-statement IF? I forgot; I've >> been thinking in REXX too long. In that case you're close; I guess I >> really meant >> > >> But in Rexx similarly, END is required even for a single-statement DO. >> Good for Rexx. I like strong closure. >> >> >In your example the END-IF is not needed. However beginning with VS >> >COBOL IIV4 (1985 standard) it became better practice to eliminate all >> >but the last period in a paragraph and terminate all conditional with >> >end statements such as END-IF. With Enterprise COBOL 5.2 and later >> >(2002 Standard) the 1050-EXIT paragraph could be eliminated and the GO >> >TOs replaced with EXIT PARAGRAPH. This allow simpler code generation >> >for the PERFORM and the PERFORMed paragraph be moved inline to in >> >effect replace the PERFORM statement. Also look up inline PERFORMs. >> >In general, because of code optimization starting with VS COBOL II >> >release 4 (1985 standard) GO TO became a bad idea. >> > >> Always a bad idea, or just usually? >> >> -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL Question
[Default] On 6 Jun 2020 10:53:44 -0700, in bit.listserv.ibm-main robhbrid...@gmail.com (Bob Bridges) wrote: >Oh, you need an END-IF even for a single-statement IF? I forgot; I've been >thinking in REXX too long. In that case you're close; I guess I really meant In your example the END-IF is not needed. However beginning with VS COBOL IIV4 (1985 standard) it became better practice to eliminate all but the last period in a paragraph and terminate all conditional with end statements such as END-IF. With Enterprise COBOL 5.2 and later (2002 Standard) the 1050-EXIT paragraph could be eliminated and the GO TOs replaced with EXIT PARAGRAPH. This allow simpler code generation for the PERFORM and the PERFORMed paragraph be moved inline to in effect replace the PERFORM statement. Also look up inline PERFORMs. In general, because of code optimization starting with VS COBOL II release 4 (1985 standard) GO TO became a bad idea. Clark Morris > > PERFORM 1050-LOOP THRU 1050-EXIT VARYING JC FROM 1 BY 1 TO 99 > > 1050-LOOP. > IF X > 999 GOTO 1050-EXIT END-IF. > IF FIRST-NAME = "ROBERT" GOTO 1050-EXIT END-IF. > IF TYPE <> 195 GOTO 1050-EXIT END-IF. > IF NOT SO-ON GOTO 1050-EXIT END-IF. > IF NOT SO-FORTH GOTO 1050-EXIT END-IF. > [do such and such] > 1050-EXIT. > >I'm happy to hear someone else admit that a GOTO is conceivable under ~any~ >circumstances. In my old shop I argued for GOTOs in three very strictly >limited circumstances, the other two being end-of-section and end-of-program. >Some languages allow for this by including some flavor of "leave" statement; >all I want to do with a GOTO is to simulate that part of structured >programming. But at the particular shop I have in mind, none of that could be >contemplated, because all GOTOs are evil. > >--- >Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 > >/* Law #21 of combat operations: The important things are always simple; the >simple things are always hard. */ > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Joe Monk >Sent: Saturday, June 6, 2020 04:49 > >I think what you mean is this: > >PERFORM 1050-LOOP THRU 1059-EXIT VARYING JC FROM 1 BY 1 UNTIL JC = 99 >END-PERFORM > > 1050-LOOP. >IF FIRST-NAME NOT = "ROBERT" >GO TO 1059-EXIT >END-IF >IF TYPE NOT = 195 >GO TO 1059-EXIT >END-IF >IF NOT SO-ON >GO TO 1059-EXIT >END-IF >IF NOT SO-FORTH >GO TO 1059-EXIT >END-IF >PERFORM 1050-SUCH-AND-SUCH END-PERFORM > > 1059-EXIT. > EXIT. > >In structured programming, it is perfectly acceptable to use GO TO within a >paragraph. It is NOT acceptable to use GO TO outside of a paragraph. > >--- On Sat, Jun 6, 2020 at 12:42 AM Bob Bridges wrote: >> I realize this is a bit of a change in subject (and it's not as if we need >> yet another one), but I avoid this construction. My phobia is based on an >> extreme example: In their zeal never to use GOTOs, I've frequently seen >> programmers write paragraphs like this: >> >> PERFORM 1050-LOOP VARYING JC FROM 1 BY 1 TO 99 >> >> 1050-LOOP. >> IF X < 1000 >> IF FIRST-NAME NOT = "ROBERT" >> IF TYPE = 195 >> IF SO-ON >> IF SO-FORTH >> EXECUTE 1050-SUCH-AND-SUCH >> END-IF >> END-IF >> END-IF >> END-IF >> END-IF >> >> Gives me a headache to try to evaluate that. Much better, in my opinion, >> to introduce ONE LOUSY "GOTO EO-PARAGRAPH" like this: >> >> PERFORM 1050-LOOP THRU 1059-LOOP VARYING JC FROM 1 BY 1 TO 99 >> >> 1050-LOOP. >> IF X > 999 GOTO 1059-LOOP. >> IF FIRST-NAME = "ROBERT" GOTO 1059-LOOP. >> IF TYPE <> 195 GOTO 1059-LOOP. >> IF NOT SO-ON GOTO 1059-LOOP. >> IF NOT SO-FORTH GOTO 1059-LOOP. >> EXECUTE 1050-SUCH-AND-SUCH >> 1059-LOOP. >> >> Keep in mind I haven't programmed in COBOL since Y2K; I had to look up the >> syntax, I probably got part of it wrong nonetheless, and I'll bet there are >> easier ways to do it nowadays. In REXX, for example, they have the ITERATE >> statement: >> >> do jc=1 to 99 >> if x>99 then iterate >> if firstname='ROBERT' then iterate >> if type<>195 then iterate >> if \soon then iterate >> if \soforth then iterate >> call suchandsuch >> end >> >> However you do it, I vastly prefer skip-
Re: z/OS 2.3 systems show OPI=YES
[Default] On 22 May 2020 12:24:27 -0700, in bit.listserv.ibm-main lenru...@gmail.com (lenru...@gmail.com) wrote: > Remember DYL-AUDIT? I wonder if it still lives? Or for that matter any of > the DYL "languages". IIRC we had DYL-260 and DYL-280 or something like that. >On Friday, May 22, 2020, 02:08:06 PM CDT, Carmen Vitullo > wrote: DYL280 became Vision:Results from Broadcom. It was a really powerful tool. I would like to see a good optimizing compiler for it. Clark Morris > > Indeed, I'm aging myself, but I remember in the mid 70's auditors coming in > the data center with their own deck, 5081's >programs that they loaded, ran their audits then left. >working for an outsourcer some time in 2001 the customer's auditors came in, >reviewed your (their) system you built, and interviewed you, they knew the >system, or appeared to. >now I'm not so confident they know what they are asking, and why > > >Carmen Vitullo > >- Original Message - > >From: "Seymour J Metz" >To: IBM-MAIN@LISTSERV.UA.EDU >Sent: Friday, May 22, 2020 1:46:08 PM >Subject: Re: z/OS 2.3 systems show OPI=YES > >You were lucky; I've encountered far too many auditors who did not know what >to look for and at best could follow a cookbook, and not always an appropriate >cookbook. OTOH, a good auditor is a resource to be treasured. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How determine local time zone *name* in Rexx?
[Default] On 18 May 2020 18:19:07 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >CRJE > >All very well for a 2741, but for a 3270 I'd much rather have SuperWylbur or >ISPF, TYVM. > >> IEHIOSUP > >My eyes! Take the bad thing away, Mommy! > >I was thinking more of Compatibility Interface and Reverse Compatibility >Interface. Is there any good reason that I can't do sequential I/O on a PS >using an ACB or sequential I/O on a (K|E)SDS using a DCB? Why is it easier in >z/VSE? I can see not having the ability to do sequential I/O on a VSAM file with a DCB but not allowing an ACB to be used for all currently data set organizations BSAM / QSAM and possibly BDAM was criminal negligence. Also not allowing the ability to concatenate a QSAM file and an ESDS was another area of short sightedness. VSE was aimed at small shops that didn't have the systems staff assumed for MVS so they had to be concerned with ease of use. Little things like dates were set using month and day not day of year. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?
[Default] On 18 May 2020 09:38:34 -0700, in bit.listserv.ibm-main peter.far...@broadridge.com (Farley, Peter x23353) wrote: >Peter, > >Thanks for your comments and questions. As I replied later in the thread, I >was incorrect in posing my original question because the file to be sent is >actually a VSAM file. Not sure at this time if it is KSDS or ESDS, as the >question was posed to me by a co-worker in another application team and I am >not aware of all the details there. This gets curiouser and curiouser. Unless the receiver of the file is either z/OS or z/VSE, how is the file going to look? Is what is actually being sent a sequential copy of the file? Also the transmitting mechanism may well have a byte count. Unless the file size is to be sent ahead of the actual transmission (I am assuming FTP or other online transport mechanism as opposed to tape or other physical medium), what can the receiver do based on the information? Is the sender supposed to do something? Clark Morris > >As I understand the current limitations of UDATASIZ and COMUDSIZ, the VSAM >file must be in "extended format" for those fields to be meaningful. Am I >correct in that understanding? > >Peter > >-Original Message- >From: IBM Mainframe Discussion List On Behalf Of >Peter Relson >Sent: Sunday, May 17, 2020 4:36 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: Is there any z/OS API to get byte file size for non-VSAM, >non-zFS, non-database files? > >Is the non-zFS "file" of the subject a data set / data set member (since we >move from HFS)? Or something else? > >I don't know what UDATASIZ and COMUDSIZ might or might not contain, but in >general the answer to the subject question is likely "no" because z/OS likely >does not keep that information. z/OS itself has no use for that information, >and maybe it's the case that there is no valid use for it in an application. > >Knowing the byte file size (which is what was asked about) is not the same as >knowing the number of records and the record size, particularly for a >variable-record-length data set, or the number of cylinders and/or tracks >and/or blocks that are allotted to the data set / member. > >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
SHARE annouce plans for an online SHARE was Re: Yechnical
[Default] On 18 May 2020 14:49:23 -0700, in bit.listserv.ibm-main charl...@mcn.org (Charles Mills) wrote: >It was yanceled due to yovid-19. SHARE in Yoston, too. Share is planning an online conference. See www.share.org. I may attend. Clark Morris > >Charles > > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Steve Beaver >Sent: Monday, May 18, 2020 1:05 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Yechnical > >Did anyone attend the Technical Disclosure meeting in NY? > > > > > > >-- >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: What crashing COBOL systems reveal about applications maintenance -- GCN
[Default] On 13 May 2020 16:56:58 -0700, in bit.listserv.ibm-main ste...@copper.net (Steve Thompson) wrote: >Suppose that they took a group of programmers and got the production online >programs to all compile with COBOL 6.2 and OPT(1). Would they see a >significant reduction in MSUs? Assuming they are running on z14s minimally? Is it likely in most environments that both the primary and fallback computers (disaster recovery) are z14 or more recent? Clark Morris > >And from that, would they actually be able to do more transactions per hour? > >Sent from my iPhone small keyboarf, fat fungrs, stupd spell manglr. Expct >mistaks > > >> On May 13, 2020, at 7:45 PM, Seymour J Metz wrote: >> >> ?Conspicuously missing from the coverage is any evidence of delays or >> outages attributable to COBOL code running on mainframes. So far the stories >> I've seen turn out to relate to web servers or manual processing, not to the >> back end. Yeah, there could be issues with, e.g., CICS transactions written >> in COBOL, but none of the stories provide any reason to believe that to be >> the case. >> >> More disturbing is the assumption that if they train hordes of COBOL >> programmers and bring all of the applications written in COBOL up to date, >> their troubles will be over. The elephant in the room is all of the code in >> other languages that has also been allowed to languish. It *all* needs to be >> documented and brought up to snuff. >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> >> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of >> Mark Regan [marktre...@gmail.com] >> Sent: Wednesday, May 13, 2020 12:21 PM >> To: IBM-MAIN@LISTSERV.UA.EDU >> Subject: What crashing COBOL systems reveal about applications maintenance >> -- GCN >> >> https://secure-web.cisco.com/1Ck2hssvPisqB8qyqrPsKlWMSh6SVj36qT95iEGNsvW41QGGjEH5TGYkmfjBEBCwAqsZp1UH2qlJxAPV-nlun5Dg56JO8lyf2QqkfAQDmic0ch6e5uj8J9A-Q3B3We8shuckCRr_XeQmGMDhXgd8TQyRlLdXH9bKy-iCiUCWHj2Kqen8MgwZNhQmpmPDXCZynS12e9_NREBCyJ-ImKut7vZYA4mccK38-ps5r3DJciC05kNl8kmdPhUg60gd1zZz7JURnW9weaJQKKDRSp57OBFh-n49E04rQSKCcaRjfOb7cGMU1n6iqgjTNOpmxmuPIjDr4aGw9aUMm9k3V6bRy75OJLSewcdQoYLb3wcGP1Iff-nYxUbFk8wp8l3lc_AhRdjTQ-059TNEsAQTLJUnMUEkSHuyT9PtOAgQrQdm_g-sdoO8Y415VmGflAy_9xBgfqdVJiOoYQb3UbkX7P6tc_A/https%3A%2F%2Fgcn.com%2Farticles%2F2020%2F05%2F12%2Fkeeping-mainframes-up-to-date.aspx%3Fm%3D1 >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM Developerworks is gone!
[Default] On 7 May 2020 19:02:28 -0700, in bit.listserv.ibm-main che...@watsonwalker.com (Cheryl Watson Walker) wrote: >Hi all, > > > >We'll I'm a little embarrassed. I was just told offline about a link that >Lionel Dyck posted here last October that described the coming of the calamity >that just occurred - https://developer.ibm.com/dw-connections-sunset-faq/. (As >a side note the creators of that FAQ werent even kind enough to create hot >links for all of the other portals. Web pages and hot links arent all that >difficult people!) The FAQ said that owners of content on DeveloperWorks could >move their content to other locations by the end of March. This is assuming >that they were still employed by IBM and had the time to move the content. Of >course, IBM could not provide them with the original content. > Does IBM somewhere have a backup of the Developer Works files? They did make backups, didn't they? Profs backups caught Ollie North. Clark Morris > >We had posted almost 100 links in our Tuning Letter to useful material on >DeveloperWorks and now none of them work. It will take time, but I hope to go >through all of our links and reach out to the authors to find where they are >now posting items. > > > >So I went to the new website - https://www.ibm.com/community/, signed up, and >started looking at it. With the optional portals listed in the FAQ and this >new community website, it just seems like IBM wants to remove as much >technical information as possible and replace it with marketing. If anyone >knows how to search the new community website, please let me know. If Im not >ready to buy a product, the community is not doing anything for me. > > > >P.S. Aled thanks for your post. I have always had the highest respect for >Timothy and Mark, and I really appreciate how much they support the customers. > > > >Still a little bitter about the deletions > >Cheryl > > > >-Original Message- >From: Cheryl Watson >Sent: Wednesday, May 6, 2020 12:39 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Cc: Cheryl Watson >Subject: IBM Developerworks is gone! > > > >Hi all, > > > >Remember when IBM went through and deleted from their websites what they >considered "old" manuals and documentation? Well, they just did it again! >They've removed all the DeveloperWorks articles that have provided such >excellent information since its creation. And these aren't just OLD articles. >Even a link from three months ago is gone. All references to DeveloperWorks >are now directed to a nothing site. The DeveloperWorks website contained >amazing articles from some of the top developers in their fields, many of whom >are no longer still working at IBM. We understand that IBM "furloughed" them, >but they don't have to furlough their ideas. > > > >I'm pleading with all of you who work for a large IBM customer to ask your >management to tell IBM to stop this idiotic practice. There is NO reason to >delete valuable information. > > > >If this is due to marketing wanting a new image, then they have no idea what >image they're creating. > > > >Please do this for all of us! > > > >All my best, > > > >Cheryl Watson > >Watson & Walker, Inc. > > > > > >-- >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: OT: But COBOL is the problem?
[Default] On 11 May 2020 10:57:42 -0700, in bit.listserv.ibm-main poodles...@sbcglobal.net (Dan at Poodles) wrote: In addition to documentation is there a good set of test data and is it kept current? One of my biggest problems in doing applications upgrade was figuring out how to test the dang thing with 20 sets of files that had to match. Clark Morris >From 46 years of experience, these problems can be mostly traced to little, if >any, documentation. Is there correct system documentation? Is there correct >file/data base documentation? Is there correct operational documentation? Is >there correct program documentation? Are the programs documented externally >(this is what this program does) and internally (explaining in excruciating >detail every action taken). Have standards been established and strictly >followed? > >Yea, I know all of this is a pain in the a$$, but who's going to support the >code should the author(s) get run over by a bus? Detailed internal program >documentation is also a great tool to review the author's logic and >assumptions. It forces programmers and managers to re-think and re-verify >everything. > >This lack of documentation can always, always, be traced to pi$$ poor >management. Just because a project is completed in record time and under >budget does not mean the project is a success. More likely than not, the poor >souls tasked with supporting these systems are left with a nightmare. They >pick up the crap they inherited and simply add more. What the hell, that was >good enough before. > >Quick and dirty one-time shots should never be placed into production. Yet, >I've seen this occur way too often. > >Whatever programming languages are used to write code is completely >irrelevant. It's all about the documentation. > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of scott Ford >Sent: Monday, May 11, 2020 11:04 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: OT: But COBOL is the problem? > >Seymour, > >Yes sir no balance between Money and quality of life per se. I feel computer >languages are our tools to get the job done. But one has to plan , work the >plan, basically execute it. This is how I learned working IBM in NYC ...it >works IMHO.. > >Scott > >-- >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
Latest COBOL standard is 2014 was Re: Cobol
[Default] On 27 Apr 2020 00:29:21 -0700, in bit.listserv.ibm-main dcrayf...@gmail.com (David Crayford) wrote: >Define modern? A language is only as modern as its last standard (or >version). For example, Python is considered a modern language although >it's 30 years old. It's constantly >being updated. Python 3.6 supports static type checking! JavaScript is >the same. C++20 is being ratified, C2x is being worked on. Java 13 is >going to GA on z/OS this year! > >It's my understanding that COBOL-85 is the current standard in use on >z/OS? That's probably indicative of COBOL programmers not requiring new >language features as they don't >need them to maintain the code bases that they work on. COBOL >modernization on z/OS has mostly been back-end optimizer work which is >probably a lot more valuable to z/OS >IT managers then new language features that won't be used. If companies >want to modernize a COBOL application they integrate with Java like CICS >and IMS. The latest COBOL standard is 2014 with 2002 and 1989 extensions being predecessors. The 2014 standard supports IEEE binary floating point plus IEEE decimal floating point with all of the rounding options including round to nearest even. There also are true binary usages including binary character and USAGE BIT along with boolean operations. There is everything needed to fully work with SMf 30 records without weird coding. It would allow a relatively straight forward conversion of Assembler DSECTS to COBOL. Because it has language to support all of the IEEE fixed and floating point binary usages, IEEE and hex floating point could co-exist in the same program. I wanted USAGE BIT 50 years ago because I was dealing with bit switches on customer, product and open account files. Clark Morris > >REXX hasn't changed in almost 30 years. There's been a few updates to >TSO REXX such as EXECIO VBS support but that's about all. > >On 2020-04-25 7:03 AM, Wayne Bickerdike wrote: >> One of our guys was talking about modern languages such as C. I said what? >> >> On Sat, Apr 25, 2020 at 7:01 AM Seymour J Metz wrote: >> >>> Well what do you know? The emperor has no clothes. We shot an innocent >>> language. >>> >>> >>> -- >>> Shmuel (Seymour J.) Metz >>> http://mason.gmu.edu/~smetz3 >>> >>> >>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf >>> of Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu] >>> Sent: Friday, April 24, 2020 3:58 PM >>> To: IBM-MAIN@LISTSERV.UA.EDU >>> Subject: Re: Cobol >>> >>> On Fri, 24 Apr 2020 18:26:49 +, Seymour J Metz wrote: >>> >>>> There are blurbs for dozens of articles; which one is relevant? I tried >>> searxhing for COBOL, but got 0 hits. >>> I suspect that was OP's desperate and futile attempt to circumvent >>> secureweb, >>> as you often do. But, I hope (posting from web interface): >>> >>> https://secure-web.cisco.com/18wMr2wQiot_mC2NJkJL7buWujrBfP9suLfEWZL4dG8gjB_Zjaj31ZgILnrnn--CfD_RooCYfsFjxvxArhRiN2V2tCmTfs8NayUQCV2ProhQ0KfRlDMDZdg2alKOSjuWwTXeK_Lci9elkht49bjva6Fj7o1W1SIr2REv9PF2NO_PK0BStoe0irBBLJRM9a_tKg3QNHj3DghbIM6_s_J2QBa8K1XWudsYnadGx1bdpDNNTapriOq_jLHjoC742AxmqQVAJ4Szwl0aLrINIHWnzPzP_p0N_kYOi4keUEoOLuWRccU_ZVES-3NC05VlKLovPbiDfx9BUbsi3Kn4nGo1sHGipsJJfPFN4ClnEGuuMjWs6LU9f2293Fm0jTt3GhayZHNNDR8prcppx857Qz_vQpR6HOUIxm-p1DAvFYE8aFU_B3Da9y60snIIWQxr9qfkI67XWmwAvbGdgFfA9cP_uBHV85oupnnYfOSco5uQPIVE/https%3A%2F%2Fwww.wired.com%2Fstory%2Fcant-file-unemployment-dont-blame-cobol%2F >>> >>> >>> From: scott Ford >>> Sent: Friday, April 24, 2020 2:08 PM >>> >>> See this url ... >>> >>> >>> http://secure-web.cisco.com/1DYCAeckpzqV94PQWw8dHuuJalhW0eVroAe-0-S4pJl_FnqGfZxS4EcWK7cCAl1oA09gJJKNMcHC1Be4KK3D-KcMIEVRVBeNOw5sf7565Z6e9CTYIm43a-oit3GGWnum7LgBTpYCxV6CAhgR9TuXipYHaUjUUPtd7BICMs1zfFGQQ8NhAeXHdXvHPrGdxzaQmTRfNi8vGWGKk4fg_G75au8H3Ja9AbLwRb2m8-upI9jYdmy1ZYdzYlRF2kzlwN155wAFEug02LCkZ5Bpk3IvSuxwzwd1UUyk_5NUmIqwMFmcDxZ8SpSnwFspncJTV1bLmByZAIVczBfj-JctXDA5Ta99YBqxx1tBpdl0qN5MWPGsz1CGAQ_Is1sLoRxy9Dl_fCLgMhLDvO5L8-EsVff2IiswF1xKvwUDiAEPcV0mOxz5c915mExQuVbCTDL0KTJQEtCF5dYTiss8HJIK_dzSG8g/http%3A%2F%2Fwww.wired.com. >>>Can't File for Unemployment - Don?t Blame Cobol >>> >>> -- gil >>> >>> -- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to lists...@listserv.ua.edu with the message: INFO IB
Re: Here we go again
[Default] On 22 Apr 2020 20:44:43 -0700, in bit.listserv.ibm-main g...@gabegold.com (Gabe Goldberg) wrote: >When I joined Mitre Corporation in 1971, my first TIAA-CREF end-of-year >retirement statement predicted benefits I'd receive starting February 1, >2012. I suspect they'd been calculating/storing/displaying 21st century >dates long before they needed one for me. Banks, insurance companies, >investment organizations, etc. handled this routinely because they had >to; no tradeoff was available for them between data storage and >now/later handling far-off dates. Others could/did ignore Y2K because >their business didn't depend on handling it. For a while. One of the disquieting things for me at SHARE Y2K sessions was all the money banks and insurance companies were spending on Y2K. Clark Morris > >Seymour J Metz said > >We had well over 20 years of warning on Y2K; management preferred to >ignore it. Apres moi le deluge (the balloon won't go up before I retire.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Here we go again;
[Default] On 22 Apr 2020 14:55:28 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >There is no on saving on forms, printer lines, punched cards, data entry >screens or data entry key strokes. You input two digits, store four digits and >print two digits. While on output truncation always works, by what rule does a program expand the input date? should a fixed window be used? a variable window based on the current date? some other rule? Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Here we go again;
[Default] On 22 Apr 2020 12:44:41 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >My first computer had a 2,000 word drum, a 60 word core memory, a 600,000 word >disk drive and two tape drives. I may have been a tad more constrained than >you were when you started. I agree with Mr. Adam; people would have saved far >more DASD space with intelligent choice of block size than the miniscule >amount they saved by truncating the year. In reviewing this discussion, I suddenly realized that the saving by using 2 digit years was not just disk and tape space but also on forms, printer lines, punched cards, data entry screens and data entry key strokes. I know that in many cases I was scrambling for space on print lines. Clark Morris > > >-- >Shmuel (Seymour J.) Metz >http://mason.gmu.edu/~smetz3 > > >From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of >Joel C. Ewing [jcew...@acm.org] >Sent: Wednesday, April 22, 2020 3:12 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: Here we go again; > >Should we presume you didn't work on mainframes prior to the advent of >cheap memory and cheap RAID DASD in TB chunks? > >Even after advent of 3380, 3390, and even native 3390-3, drives our >company didn't lease DASD drives without doing cost analysis. In late >1970's and early 1980's we were on 3330's and later 3350's, where >physical constraints were also an issue -- when I started as SysProg in >1978, the computer room was maxed out space-wise at 29 3330 drives, or >only 2.9GB total DASD space. We didn't have DASD sitting around that >wasn't 95% or more utilized. Batch jobs typically got one dedicated >3330 DASD work volume that they could allocate only for the duration of >the job stream, staging data from/to tape as necessary to fit and to >preserve for next job-stream run. It wasn't until 1995 and beyond, >that it finally made economic sense for us to acquire DASD capacity a >year or two before we might actually be able to justify a need. > >Our company believed in investing more money in people to retain good IT >personnel rather than throwing money at hardware. That mind-set was one >of the reasons why of the 50 some-odd companies in that line of >business in 1950, of the 3 still in business in 2000, one was ours. > >Saving one or two bytes per date field in that kind of environment was >not "marketing nonsense". By performance tuning and efficient >application design we consistently delayed the need for a DASD or >processor upgrades, resulting in *considerable* monetary savings over >decades. You don't "waste" DASD or memory space just because it's >available at the time without first considering the long-term impact on >future upgrades. A "good" programmer/analyst was trained to err on the >side of conserving resources. > >You can't judge decisions of the past without first understanding the >cost, physical space, memory, and I/O configuration constraints under >which those decisions were made. Unlike now where where easy >incremental upgrades are possible, back then every upgrade, assuming one >was possible, involved a substantial cost increase. >JC Ewing > >On 4/22/20 12:05 PM, Gerhard adam wrote: >> >> >> >> >> The notion of savings was marketing nonsense. The DASD was paid for >> regardless of whether it held a production database or someones golf >> handicap. >> It cost the same whether it was empty or full. The notion of saving was >> nonsense and even under the best of circumstances could only be deferred >> expenses >> >> >> >> Get Outlook for iOS >> >> >> >> >> >> >> On Wed, Apr 22, 2020 at 10:01 AM -0700, "David Spiegel" >> wrote: >> >> >> >> >> >> >> >> >> >> >> It was also the physical size of the dataset. >> >> On 2020-04-22 12:55, Gibney, Dave wrote: >>> In the 80's a byte of DASD savings could be thousands of dollars. >>> >>>> -Original Message- >>>> From: IBM Mainframe Discussion List On >>>> Behalf Of Phil Smith III >>>> Sent: Wednesday, April 22, 2020 9:12 AM >>>> To: IBM-MAIN@LISTSERV.UA.EDU >>>> Subject: Re: Here we go again; >>>> >>>> As others have suggested, many companies do still have SSNs stored as >>>> packed decimal. So sure, a namespace expansion is possible, but it's a >>>> bigger >>>> change than one might think, however it's done. I've even seen at least one >>>>
Re: Here we go again
[Default] On 21 Apr 2020 22:43:34 -0700, in bit.listserv.ibm-main sipp...@sg.ibm.com (Timothy Sipples) wrote: >Mark Jacobs wrote: >>The Social Security Administration does not reuse Social Security >>numbers. It has issued over 450 million since the start of the >>program, and at a use rate of about 5.5 million per year. It says >>it has enough to last several generations without reuse or changing >>the number of digits. > >The Social Security Administration could easily give 20 years of advance >warning before expanding their number space if they wish. They've got >several options before that far distant future, such as: > >1. Allowing capital letters except those that can be confused with numeric >digits. That'd likely mean excluding B, D, F, G, I, L, O, Q, S, T, U, Y, >and Z if they want to be maximally cautious. That still leaves 13 letters >available, or 14 if they want to include the symbol representing the >artist formerly known as Prince. :-) They'll also probably have some >placement exclusions to avoid spelling out any words. Even with these >restrictions, the character space is vast. The fun would come for programs like the now retired payroll programs I wrote that stored social security numbers as packed decimal. Clark Morris > >2. Alternatively, and in an overlapping period, some brand new digital >identity scheme. > >- - - - - - - - - - >Timothy Sipples >I.T. Architect Executive >Digital Asset & Other Industry Solutions >IBM Z & LinuxONE >- - - - - - - - - - >E-Mail: sipp...@sg.ibm.com > >-- >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: Here we go again
[Default] On 21 Apr 2020 01:45:25 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >My guess is that they needed to update the online application to support the >new legislation, that it is written in COBOL for CICS, that they negligently >failed to require, or even allow, adequate documentation and that they're too >cheap to maintain adequate staffing. There are other possibilities, but they >all boil down to poor management or inadequate funding and have nothing to do >with the choice of language. IMHO a decent programmer could quickly pick up >enough COBOL, JavaScript or whatever to do a quick fix, even if the code >wasn't as clean or efficient as he could have written with more experience. >Overcoming a lack of good documentation, however, is something else. "Remember >that after Heracles cleaned the Augean stables, he killed the man who asked >him to do it." = Robert Townsend in "Up The Organization" At this point they need to bring back people who know the system. I'm a retired DOS 360 COBOL payroll and marketing programmer, retired MVT, MVS, HASP, JES3 and JES2 systems programmer with submissions on the MICHMODS, JES3 and CBT tapes, applications technical support for LE upgrade and Y2K at an installation who developed in COBOL the date routine which I am 99% certain was faster than the COBOL functions and I still keep up with both the z systems via ibm-main and COBOL via comp.lang.cobol as well as downloading selected manuals. My specialty is debugging, modifying and improving existing code. In a crisis situation these skills would be useful only if I understood the system that was to be changed. Clark Morris > >As you noted, overloading is an unrelated issue. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IPCS LIST command to display storage when pointer is in a different address space
[Default] On 21 Apr 2020 02:09:14 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >Can't you do it incorrectly via an intermediate EQUATE or EVALUATE subcommand? Incorrectly or indirectly? Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] Re: New Jersey Pleas for COBOL Coders for Mainframes Amid Coronavirus Pandemic
[Default] On 13 Apr 2020 11:32:51 -0700, in bit.listserv.ibm-main rpomm...@sfgmembers.com (Pommier, Rex) wrote: >What's the definition of "volunteer"? The articles I've read say they're >looking for volunteers, although I can't believe they're looking for somebody >to work for free! I'm considering actually putting a truncated resume online in Linked In and offering to do things such as review compile options. Given that I am required to stay home due to Covid-19 and I wouldn't want any confidential information on my computer, the sort of help is that which I would provide a fellow SHARE member. For billing concerns thee only pay project I would consider is in Canada. Clark Morris > >-Original Message- >From: IBM Mainframe Discussion List On Behalf Of >Dan at Poodles >Sent: Monday, April 13, 2020 1:24 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: [External] Re: New Jersey Pleas for COBOL Coders for Mainframes Amid >Coronavirus Pandemic > >Nobody asked the real question: "What are they paying?". > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Pommier, Rex >Sent: Monday, April 13, 2020 11:22 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: [External] Re: New Jersey Pleas for COBOL Coders for Mainframes >Amid Coronavirus Pandemic > >Yup, this whole thing is akin to somebody complaining that Windows Server >2019 is ancient as well. I'm sure if you dig a bit, you'll find code inside >it based on NT technology from the 1980s so why aren't people complaining >about that? > >-Original Message- >From: IBM Mainframe Discussion List On Behalf Of >Seymour J Metz >Sent: Monday, April 13, 2020 10:51 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: [External] Re: New Jersey Pleas for COBOL Coders for Mainframes Amid >Coronavirus Pandemic > >Sigh! The system may be 40 years old but the computer in the picture is a lot >older. > >I suspect that the "40 year old" system is like the ax that has been in use >for 200 years: the handle has been replaced 20 times and the blade has been >replaced 25 times, but it's still the same ax. > > > >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 > >-- >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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
