Re: Modernize Mainframe Applications for Hybrid Cloud with IBM and AWS

Perhaps no one has :grokked" the difference is because either there isn't one or because it is so poorly explained and discussed as to be non-existent. This sounds like more marketing hype perpetrated by individuals that know buzzwords and little else. -Original Message- From: IBM

Re: Assembler analysis [was: RE: Serverpac installs January 2022 and beyond - Issues]

> ITYM TANSTAAFL, as originally coined by Larry Niven(?) Robert Heinlein, "The Moon is a Harsh Mistress" -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Monday, November 1, 2021 2:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Assembler analysis

Re: Programs that work right the first time.

, 2021 6:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Programs that work right the first time. Someone's height is a pretty good measure of where they lie on the scale of adulthood. Except for a small percentage of outliers. On Tuesday, August 24, 2021, 08:48:26 AM EDT, Gerhard Adam

Re: Programs that work right the first time.

> length isn't a good measure of complexity Really? Who dreams up this nonsense? Define "complexity" and then perhaps an argument can be made about causes or measurements. Until then it is a silly claim. Length is NOT a MEASURE of complexity any more than height is a measure of adulthood.

Re: Programs that work right the first time.

It simply seems that most of the comments demonstrate that most posters have no idea what they are doing. (1) Programs are not complex, problems are. If the program is complex and the problem is not, then you don't know what you are doing. (2) Programming is not intended to show how smart

Re: SMPE

There is only one relevant zone; the TARGET for the system being examined. The GLOBAL zone may have FMIDs deleted depending on the ACCEPT options and items may not even be APPLIED (if they have only been RECEIVEd).The DLIB zone will only show elements that have been ACCEPTed. The PRODUCT

Re: How to compare parameters in one z/Os with parameters in another z/OS

Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard Adam Sent: Sunday, June 13, 2021 6:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: How to compare parameters in one z/Os with parameters in another z/OS There is no getting around the manual examination that is requir

Re: How to compare parameters in one z/Os with parameters in another z/OS

There is no getting around the manual examination that is required. Once this is completed then you can evaluate whether parameters should be shared, copied, etc. to establish how they are to managed into the future. There is no other way, since it seems that no one knows that has actually

Re: How to compare parameters in one z/Os with parameters in another z/OS

There is a utility program (IEBCOMPR) and functions like SuperCompare to do this. It is quite trivial. Unless you mean that these libraries are not truly comparable in which case no comparison is possible. Under those conditions you would have to have a program which could have specific

Re: DFSMS Move Dataset

DFSMSdss will do and it can also be invoked from ISMF where a filter list can be build for the files to be moved Get Outlook for iOS On Fri, May 15, 2020 at 10:41 AM -0700, "esst...@juno.com" wrote: Hello. Does IBM (DFSMS)

Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?

ng something exactly as the OP suggests. It is equally wrong to assume there could be no good reason for doing it the OP's way. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard adam Sent: Thursday, May 14, 2020 1

Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?

It is easy to say that a COBOL program needs to “know” this but it is nonsense since there is nothing a COBOL program can do with this info. If it turns out to really be necessary then a subroutine can be written (as it has been done for decades) to provide this

Re: Is there any z/OS API to get byte file size for non-VSAM, non-zFS, non-database files?

Rightfully people would like to know what the purpose is.  It isn’t simply a question of acquiring the info, but also what you intend to do about it afterwards.  Since the question pertains to COBOL I’m guessing they haven’t thought that far ahead

Re: z/OS performance question

Delays don’t really count for anything unless we know that these jobs are missing their objectives and by how much.  Delays always occur. If the jobs are meeting their objectives then there is no performance problem (as far as the system is concerned).  The problem, then,

Re: [External] Re: Here we go again;

as cheaper the STOPX37. I'm not cheaper today. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Gerhard adam > Sent: Wednesday, April 22, 2020 3:44 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [External] Re: Here we go again; > > > >

Re: [External] Re: Here we go again;

arly full you have to pay for another. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard adam Sent: Wednesday, April 22, 2020 10:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Here we go again; The notion o

Re: Here we go again;

uration 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: > > >

Re: [External] Re: Here we go again;

blocking. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gerhard adam Sent: Wednesday, April 22, 2020 2:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [External] Re: Here we go again; ... and so goes the mythology.  The truth is that p

Re: [External] Re: Here we go again;

en I moved into systems programming I got to be the one going to the developers and making sure they didn't use bad blocking. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gerhard adam Sent: Wednesday, April 22, 2020 2:20 PM To: IBM-MAIN@LISTSERV.UA.EDU S

Re: Here we go again;

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.   

Re: [External] Re: Here we go again;

ERV.UA.EDU] On Behalf Of Gerhard adam Sent: Wednesday, April 22, 2020 10:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Here we go again; The notion of “savings” was marketing nonsense. The DASD was paid for regardless of whether it held a production database or some

Re: Here we go again;

The notion of “savings” was marketing nonsense.  The DASD was paid for regardless of whether it held a production database or someone’s golf handicap. It cost the same whether it was empty or full.  The notion of “saving” was nonsense and even under the best of

Re: New Jersey Pleas for COBOL Coders for Mainframes Amid Coronavirus Pandemic

COBOL is not taught because those that know it can make a much better living using it than teaching college classes to people that believe it is “dead” Of course the latter opinion is stupid on the face of it.  After all, how does one replace systems that are not

Re: Wanted Civil programmers in New Jersey urgently

Most of it is BS.  Scratch the surface and you usually find capacity or performance issues around the Windows servers while the management blithely blames the mainframe because they don’t know how anything works. Get Outlook for iOS On

Re: What is a mainframe?

I think you are absolutely correct There is a reason why VTAM adopted APPN, because it was impossible for VTAM to look and behave as if it were the entire center for every communications need. TCP/IP was inevitable given its large penetration into the home consumer market and the cost for

Re: MIPS chart for all IBM hardware model

You can see it on the IBM site (search -SRM Constant ). You should also see it in the Planning WLM manual, I believe Appendix B MIPS do NOT exist, and are simply made up numbers.They are a loose conglomeration that is similar to ITR. (where a 370/158 is considered a 1 MIPS machine).

Re: CA OPS/MVS

If you don't mind, please forward them to me. I do work with CA customers and would be interested in what you have Thanks Gerhard -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter X. DeFabritus Sent: Friday, March 29, 2019 2:45 PM To: IBM-MAIN@LISTSERV.UA.EDU

Re: Rebuilding IODF

I'm confused. How is anything running? What about other LPARs? Sent from my iPhone > On Jun 17, 2018, at 11:52 PM, Mainframe Sysprog > wrote: > > Thanks for the suggestions, will suggest these, and post further updates as > I get them. > > The IODF version that he has found so far is

Re: Use of dynamic system symbols in JCL

tin > <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > >> On Sat, 9 Jun 2018 16:13:34 -0700, Gerhard Adam wrote: >> >> This is the JCL Reference for z/OS 2.3 (page 183) >> >> Note: >> 1. In general, the system treats a single ampersand (&)

Re: Use of dynamic system symbols in JCL

MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Jaffe Sent: Saturday, June 9, 2018 3:03 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Use of dynamic system symbols in JCL On 6/9/2018 2:49 PM, Gerhard Adam wrote: > Actually it is documented as well as using double ampersands for symbols > (deferred usage) a

Re: Use of dynamic system symbols in JCL

Actually it is documented as well as using double ampersands for symbols (deferred usage) and the use of the ampersand as a part of the name. Adam Sent from my iPhone > On Jun 9, 2018, at 11:24 AM, Ed Jaffe wrote: > >> On 6/6/2018 8:51 AM, Steve Smith wrote: >> This has been previously

Re: empty KSDS behavior - why?

Perhaps a silly question, but were these files allocated with RECOVERY or SPEED? IIRC, RECOVERY pre-formats the first control area with binary zeros. In other words, does changing this specification change the behavior? Adam Sent from my iPhone > On May 29, 2018, at 3:12 PM, Frank Swarbrick

Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

I personally used SMP in 1975 on a S/360 running MFT. Sent from my iPhone On May 23, 2018, at 8:29 PM, Edward Gould <edgould1...@comcast.net> wrote: >> On May 23, 2018, at 2:13 PM, Gerhard Adam <gada...@charter.net> wrote: >> >> SMP was available in MVT and M

Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

om: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Paul Gilmartin > Sent: Wednesday, May 23, 2018 2:40 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [External] Old School Maintenance Philosophy -- Never ACCEPT? > >> On Wed, 23 May 2018 1

Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

I think the reference may have been to the older SMP CDS which played the role of the current CSI Sent from my iPhone > On May 23, 2018, at 11:03 AM, Seymour J Metz wrote: > > The PTS, among others, was a PDS. SMP used very strange member names. There > was no CSI, no zones.

Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

Sorry, but the CSI was never a PDS and still isn't. I suspect you're thinking of the PTS Sent from my iPhone > On May 23, 2018, at 10:00 AM, Nims,Alva John (Al) wrote: > > " I learned to use SMP back on MVT (am I the only one still here that can > truthfully make that

Re: Old School Maintenance Philosophy -- Never ACCEPT?

Why bother? Do a RESTORE GROUP CHECK and get that information. Sent from my iPhone > On May 23, 2018, at 9:08 AM, Tom Marchant > <000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > >> On Wed, 23 May 2018 10:07:16 -0400, John Eells wrote: >> >> As others have pointed out, it makes

Re: [External] Old School Maintenance Philosophy -- Never ACCEPT?

I also don't recall a "never ACCEPT" policy. That would be silly because it becomes a "never RESTORE" policy. Sent from my iPhone > On May 23, 2018, at 7:08 AM, David L. Craig wrote: > >> On 18May23:1247+, Pommier, Rex wrote: >> >> Not sure how long ago eons was, but

Re: WLM?

UA.EDU >> Subject: Re: WLM? >> >> [External Email] >> >> I understand the words in your response but I still don't >> understand. How is it possible that it takes over 800 SUs to respond >> to and Infoprint daemon? What am I missing here? >>

Re: WLM?

BTW, the reason your Infoprint work suffers is most likely due to it having an Importance level of 5. If you make that higher, then it should ensure that Infoprint gets serviced by WLM to ensure its goals are being met [regardless of the velocity or response time settings]. Adam -Original

Re: WLM?

The first two periods are ALWAYS used, but the duration limits how long the work stays there before it transitions into the next period. So, if most of our work is in period 3, it's because it has exceeded the 800 SU's that have been designated in the previous periods. Adam -Original

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

It seems your picking a fight that doesn't exist. The IRS, has not had a problem complying with the tax code, nor in processing returns. Software was clearly changed and capable of doing what was needed. COBOL was never intended to interface directly with networking software so it was no

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

ilmartin > Sent: Friday, April 20, 2018 3:13 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] IRS - 60-Year-Old IT System Failed on Tax Day Due to > New Hardware (nextgov.com) > >> On Fri, 20 Apr 2018 07:14:20 -0700, Ger

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

018, at 12:13 PM, Paul Gilmartin > <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > >> On Fri, 20 Apr 2018 07:14:20 -0700, Gerhard Adam wrote: >> >> Applications don't get old. They either do what they're supposed to do or >> they don't. It has

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

Applications don't get old. They either do what they're supposed to do or they don't. It has nothing to do with age. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Smith, Nathan (ATLANTA, GA) Sent: Friday, April 20, 2018 6:13 AM

Re: IRS - 60-Year-Old IT System Failed on Tax Day Due to New Hardware (nextgov.com)

Well, it's rather obvious that the people that wrote this article are about as ignorant as they come. Sent from my iPhone > On Apr 19, 2018, at 3:47 PM, Nash, Jonathan S. > <01abdcef2f3c-dmarc-requ...@listserv.ua.edu> wrote: > > IRS - 60-Year-Old IT System Failed on Tax Day > Due to New

Re: The IRS Really Needs Some New Computers

Since I was actually in the IRS data center a few months ago, the idea of 30 year old technology is absurd. Sent from my iPhone > On Apr 17, 2018, at 1:22 PM, Ed Jaffe wrote: > >> On 4/17/2018 11:09 AM, Allan Staller wrote: >> The IRS has been trying to upgrade

Re: The IRS Really Needs Some New Computers

Nonsense, the IRS is running Z/13's , etc. Sent from my iPhone > On Apr 17, 2018, at 11:09 AM, Allan Staller wrote: > > The IRS has been trying to upgrade both hardware and software for at least 30 > years I am aware of. > It keeps getting shot down by Congress in the

Re: Many arguments to a Rexx function call

2018 14:31:18 -0700, Gerhard Adam <gada...@charter.net> wrote: >Just seems like a lot of discussion trying to pass 22 arguments, when the >limit is 20. > You're right. Only, as I was not aware of the existence of that limit... >After that it's merely a question of

Re: Many arguments to a Rexx function call

433f07816-dmarc-requ...@listserv.ua.edu> wrote: > >> On Mon, 9 Apr 2018 09:29:22 -0700, Gerhard Adam wrote: >> >> If you need to include all 22 arguments, just make the last one bigger and >> parse it a second time to get the resu

Re: Many arguments to a Rexx function call

If you need to include all 22 arguments, just make the last one bigger and parse it a second time to get the results. For example: 01 /* REXX */ 02 rs = ALERTSN(SEV,TYPENAME,ELEMENT,DESC,STATUS,STSDESC,,

Re: Many arguments to a Rexx function call

Normal continuation rules would apply, but it appears that there is a limit of 20 arguments. You have 22, which produces the error Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Phil Smith III Sent: Friday, April 6, 2018 3:25

Re: WLM and Dispatching Priority

Agreed. That's not a problem and with multiple service classes, one would expect multiple dispatching priorities to be assigned to the enclaves. However, that suggests that when the address space is displayed, such considerations shouldn't matter. We aren't displaying the enclave or any other

Re: WLM and Dispatching Priority

channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA From: Gerhard Adam <gada...@charter.net> To: IBM-MAIN@LISTSERV.UA.EDU Date: 05/04/2018 18:49 Subject:Re: WLM and Dispatching Priority Sent by:IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> I do

Re: WLM and Dispatching Priority

ching priorities such that there is an unoccupied priority between each occupied priority. This process is referred to as priority unbunching. The dispatching priority is recorded in the subtype 2 records. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf

Re: WLM and Dispatching Priority

[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Thursday, April 5, 2018 9:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WLM and Dispatching Priority On Thu, 5 Apr 2018 08:37:20 -0700, Gerhard Adam wrote: >I don't see the relevance of enclaves or anything e

Re: WLM and Dispatching Priority

unbunching. The dispatching priority is recorded in the subtype 2 records. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard Adam Sent: Thursday, April 05, 2018 12:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WLM and Dispatching

Re: WLM and Dispatching Priority

ities to the > workload. > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Gerhard Adam > Sent: Thursday, April 05, 2018 11:37 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: WLM an

Re: WLM and Dispatching Priority

I don't see the relevance of enclaves or anything else in this. It is the service class period that matters. So, if I assigned DB2, enclaves, TSO, and batch to the same service class, they should still all have the same dispatching priority. Workload Manager doesn't care what type of work is in

Re: WLM and Dispatching Priority

While multiple periods certainly makes sense, the idea that different dispatching priorities exist within a single period service class doesn't. Workload manager adjusts the dispatching priority of an entire service class, both in terms of "unbunching" and in the algorithms used to assess the

Re: WLM and Dispatching Priority

DB2P_CTL 255 DBH1DBM1 DB2P_CTL 246 DBK1DIST DB2P_CTL 246 DBK1DBM1 DB2P_CTL 246 DBH1DIST DB2P_CTL 246 Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Gerhard Adam > Sent: 05 April, 2018 13:23 &g

Re: WLM and Dispatching Priority

@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Thursday, April 5, 2018 5:50 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: WLM and Dispatching Priority Gerhard Adam wrote: >Has anyone ever seen something like this before? Two started tasks {both DB2 >address spaces] in the same service

Re: WLM and Dispatching Priority

Has anyone ever seen something like this before? Two started tasks {both DB2 address spaces] in the same service class and yet have different dispatching priorities? This screen capture shows the essential details. Any thoughts? Adam

Re: WLM and response time

for the policy adjustment cycle. > > Further suggested reading SYSTEM Programmers Guide to WLM: > > www.redbooks.ibm.com/redbooks/pdfs/sg246472.pdf > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Gerhard

Re: WLM and response time

elocity calculation > to include queue time as part of the delay. > > Suggested reading: ftp://public.dhe.ibm.com/s390/zos/wlm/WLMvelocity.pdf > > HTH, > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > B

Re: WLM and response time

For additional clarification, consider a batch response time goal of 10 minutes. If we assume 5 initiators, and the service class is managed by transaction class for these 5 initiators, then how do I not risk have a policy adjustment interval where there is only one response time sample in any

Re: WLM and response time

Well, this may seem like an obvious answer, but I can't tell if I'm confusing myself or missing something. If I use a long response time (like 10 minutes for batch), then I would think that I only consider that during the Performance Adjustment interval in which the transaction ends. Yet that

Re: Help with JES2 Offloader

It might be appropriate to have a REXX/SDSF routine that can select the work you are interested in, and perhaps set a unique DESTID to differentiate it from other work. After that, the OFFLOAD is straightforward. Adam -Original Message- From: IBM Mainframe Discussion List

Re: Problem with JCL

Why not simply make Part B and Part C, separate jobs and use IEBGENER to submit them to the internal reader based on condition code? If they can't reside in a PDS, then make them instream data to be passed to the IEBGENER based on return code. Adam -Original Message- From: IBM

Re: Problem with JCL

Sorry, but how is this not just a standard condition code test? Sent from my iPhone > On Jan 31, 2018, at 4:45 AM, Jantje. wrote: > >> On Tue, 30 Jan 2018 15:36:29 +, Ward Able, Grant >> wrote: >> >> I have a situation where I need to execute a

Re: SYSOUT not accumulated

While I don't know what product you're referring to, but clearly there can be no problem with JES if you have output in class D Sent from my iPhone > On Jan 29, 2018, at 8:26 PM, Peter wrote: > > Hello > > We have updated the output class D in our JES output reporting

Re: VSAM Performance - CPU reduction

To me it still looks like you don't have enough index buffers. My calculation suggests you need at least 137 buffers to keep the index set in memory. Sent from my iPhone > On Jan 7, 2018, at 10:21 AM, Arun Venkatratnam > wrote: > > Ron, > > About 80% of

Re: VSAM Performance - CPU reduction

Seems a bit round-about. Why not REPRO them to a sequential file, sort by key, and then produce your output. Sent from my iPhone > On Jan 5, 2018, at 4:20 PM, Arun Venkatratnam > wrote: > > Hi All, > > We are looking to improve the performance of a COBOL

Re: How to find the Global zone names in SMP/E via REXX

Isn't that the point of getting a file allocation report with every SMP run? Adam Sent from my iPhone On Aug 9, 2017, at 7:58 PM, Edward Gould wrote: >> On Aug 9, 2017, at 4:34 PM, Paul Gilmartin >> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: >> >>> On

Re: JES2 Checkpoint question

d both of them, so > there is nothing to reconfigure. A COLD start would indeed be the fastest. > > Kees. > >> -Original Message- >> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >> Behalf Of Gerhard Adam >> Sent: 28 July, 2017 18:1

Re: JES2 Checkpoint question

received I/O errors on the CKPT files, due to time constrains on my downtime I had to get the systems back up. I've since read there are somethings I could have tried to recover, but at the timethere was no time. Carmen - Original Message - From: "Gerhard Adam&q

Re: JES2 Checkpoint question

You shouldn't need both on DASD. However, I am curious as to why you had to COLD start. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carmen Vitullo Sent: Friday, July 28, 2017 6:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: JES2

Re: REGION=0M leads to CPU through the roof

I don't see paging as the culprit. To page out 1.6 GB of memory and then reference it to bring it back in still indicates an application problem. Especially with a total elapsed time of only 12 minutes. I suspect that the application built a table. Spent wasted time searching it. Sent from

Re: REGION=0M leads to CPU through the roof

What's strange to me, is that the program used up all the available storage indicated by coding REGION=0M. This clearly means that the program is dynamically adjusting the amount of storage that it needs based on the available region. After all, if it were of fixed size, then coding 0M

Re: REGION=0M leads to CPU through the roof

[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard Adam Sent: Monday, July 24, 2017 3:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: REGION=0M leads to CPU through the roof How much did the elapsed time change? I find it hard to believe that the job actually ran 22 x longer and that wasn't

Re: REGION=0M leads to CPU through the roof

How much did the elapsed time change? I find it hard to believe that the job actually ran 22 x longer and that wasn't notable as a difference. Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Way, Richard Sent: Monday, July 24,

Re: Cobol-calling-Asembler and 24bit mode

Never mind, just noticed that that point had already been made. Sent from my iPhone > On May 20, 2017, at 12:54 PM, Charles Mills wrote: > > Is my understanding correct? > > - the call from COBOL to assembler is dynamic; that is, the assembler > programs are separately

Re: Cobol-calling-Asembler and 24bit mode

Why not simply make the program AMODE 31 and RMODE 24? Sent from my iPhone > On May 20, 2017, at 12:54 PM, Charles Mills wrote: > > Is my understanding correct? > > - the call from COBOL to assembler is dynamic; that is, the assembler > programs are separately linkedited

Re: SDB (system determined Blksize)

I don't see how the space would not be wasted. Where would it be assigned or accounted for? If you ignored such waste, you could have more capacity available than the volumes you've defined. Sent from my iPhone On May 20, 2017, at 10:40 AM, Charles Mills wrote: >> if you

Re: SDB (system determined Blksize)

>I'm skeptical that layer(s) of emulation incur no performance penalty. >Wouldn't a hypothetical emulated device supporting two 32760-byte blocks per >track, or one 65535-byte block (the CCW count field) >do better? What files would benefit? Other than sequential files, what files will benefit

Re: SDB (system determined Blksize)

z/OS doesn't emulate 3390's, the disk technology does. It also does so, for good reason, because the biggest issue with DASD is differing geometries. That would affect space allocation and the blocksizes that can be used. Since there is no performance penalty for emulating a 3390, there is

Re: SDB (system determined Blksize)

I'm not sure why you think these are competing efficiencies. A large physical block reduces waste on the track by requiring fewer Inter-Block Gaps (IBG) and it reduces the number of I/O's required to read the data. The problem is that the maximum blocksize was limited by software to 32K.

Re: Terminology - Datasets

I think that it's often a lot of fuss for nothing. I don't believe anyone is confused if I refer to a VSAM file, or a UNIX file, or a UNIX directory, or a PDS. Invariably we qualify what we are talking about when we have to be specific. Beyond that, I don't see it as particularly relevant.

Re: Terminology - Datasets

Typically a "dataset" is MVS - z/OS, while a "file" is UNIX. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Porowski, Kenneth Sent: Wednesday, April 26, 2017 8:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Terminology - Datasets >From

Re: Draining JES2 SPOOL volume

Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard Adam Sent: Tuesday, January 24, 2017 2:53 PM To: IBM-MAIN

Re: Draining JES2 SPOOL volume

Ok, so how about spool offload? Sent from my iPhone > On Jan 24, 2017, at 2:55 PM, Pew, Curtis G <curtis@austin.utexas.edu> > wrote: > >> On Jan 24, 2017, at 4:46 PM, Gerhard Adam <gada...@charter.net> wrote: >> >> I'm confused. I thought you wer

Re: Draining JES2 SPOOL volume

@LISTSERV.UA.EDU Subject: Re: Draining JES2 SPOOL volume On Jan 24, 2017, at 4:12 PM, Gerhard Adam <gada...@charter.net> wrote: > > Have you looked at, or tried the $MSPL command? I looked at it, but it didn’t fit what I was trying to do. -- Pew, Curtis G curtis@austin.utexas.edu ITS

Re: Draining JES2 SPOOL volume

G Sent: Tuesday, January 24, 2017 2:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Draining JES2 SPOOL volume On Jan 24, 2017, at 4:12 PM, Gerhard Adam <gada...@charter.net> wrote: > > Have you looked at, or tried the $MSPL command? I looked at it, but it didn’t fit what I was

Re: Draining JES2 SPOOL volume

Have you looked at, or tried the $MSPL command? Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Tuesday, January 24, 2017 12:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Draining JES2 SPOOL volume Exactly

Re: Looking for USERMOD samples

What you have will look something like this: //SMPCNTL DD * SET BDY(GLOBAL). RECEIVE SELECT(FMN2001) SYSMODS. SET BDY (TARGET). APPLY SELECT(FMN2001) RETRY(YES) REDO. /* //SMPPTFIN DD DATA,DLM=$$ ++USERMOD (FMN2001) REWORK(201601) . ++VER (Z038) FMID(JADLD12) PRE(UI25246) . ++JCLIN. //

Re: Looking for USERMOD samples

Look in the SMP/E Reference manual, in the section for ++SRC. There are some specific examples that will help. Adam -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, December 27, 2016 1:55 PM To:

Re: new JES2 MAS jobs will not run on member 2

and along those lines I think my other issue is I don't need APPL(LITJES2A) NODE=1 <-- this is member( 1) APPL(LITJES2C) NODE=1 <--- this is member(2) APPL(LITJES2T) NODE=2 APPL(A6504JEA) NODE=4 - Original Message - From: "Gerhard Adam" <gada...@charter.net> To: IBM-MAI

Re: new JES2 MAS jobs will not run on member 2

List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard Adam Sent: Sunday, December 04, 2016 3:51 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: new JES2 MAS jobs will not run on member 2 Not sure what you're doing but a MAS certainly doesn't require an IPL, nor does it use the /*JOBPARM

Re: new JES2 MAS jobs will not run on member 2

arkansasbluecross.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard Adam Sent: Sunday, December 04, 2016 3:51 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: new JES2 MAS jobs will not run on member 2 Not sure what you're doing

Re: new JES2 MAS jobs will not run on member 2

Not sure what you're doing but a MAS certainly doesn't require an IPL, nor does it use the /*JOBPARM statement. If there is an initiator available, it will pick up the job. Sent from my iPhone > On Dec 4, 2016, at 1:13 PM, Vitullo, Carmen P > wrote: > > I just

  1   2   >