Re: Java problem

I've gone thru the install steps I had to perform for an SAP product (heavy java user), so this might be helpful as well. The userids for this product should be defined with: ASSIZEMAX=2147483647 and MMAPAREAMAX=16777216 Regards, ---

Re: Java problem

H maybe MemLimit and SHMemMax on OMVS segment are also good parms to check/increase. Lucas On May 7, 2016 06:06, "Phil Smith III" wrote: > Rob Schramm offered: > >ASSIZE will set the user limit for storage. Set via RACF. > > Still no, unless I misunderstood (quite possible!): > > DEFAULT-GR

Re: Java problem

Rob Schramm offered: >ASSIZE will set the user limit for storage. Set via RACF. Still no, unless I misunderstood (quite possible!): DEFAULT-GROUP=SYS1 PASSDATE=14.197 PASS-INTERVAL=N/A PHRASEDATE=N/A ATTRIBUTES=SPECIAL OPERATIONS ATTRIBUTES=AUDITOR REVOKE DATE=NONE RESUME DATE=NO

Re: Java problem

ASSIZE will set the user limit for storage. Set via RACF. Rob Schramm On Fri, May 6, 2016, 9:59 PM Phil Smith III wrote: > Hmm. Good input, thanks. Either OMVS or SSH produces the error. When run > from batch, it seems to work (I say "seems to" because I didn't run it > myself, but the job out

Re: Java problem

Hmm. Good input, thanks. Either OMVS or SSH produces the error. When run from batch, it seems to work (I say "seems to" because I didn't run it myself, but the job output shows it working). I have a 2.1 system too, so I did D OMVS,L on both. They were quite different, and the high-water mark for S

Re: Java problem

Question 1. Are you OMVS from TSO or connecting via SSH? Rob Schramm On Fri, May 6, 2016 at 7:45 PM Lucas Rosalen wrote: > If I recall it correctly, it's either MAXSHAREPAGES and/or SHRLIBRGNSIZE > parms in BPXPRMxx. > > Regards, > > > --

Re: Using TYPE=MEMORY (or VIO?)

On 5/6/2016 1:44 PM, Jesse 1 Robinson wrote: STORGRP SGVIO VIO NAME TYPE MAXSIZE UNIT --(2)--- ---(3)-- --(4)-- (5)- VIODAVIO 13500 3390 Compared with Ed, we have a very low limit indeed. VIO MaxSize is expressed in K-bytes

Re: Mounting Unique zFS for SMPE APPLY

True thing! If SMPE is pointing to some directory that's not the "hot" one (under /Service, usually), then no SMPE update would be required. Simply mounting the "new" filesystem under the correct directory would work. If SMPE is pointing to the "hot" path (which is weird), then it would require eit

Re: Java problem

If I recall it correctly, it's either MAXSHAREPAGES and/or SHRLIBRGNSIZE parms in BPXPRMxx. Regards, --- *Lucas Rosalen* Emails: rosalen.lu...@gmail.com / *lrosa...@pl.ibm.c

Java problem

(Already posted to MVS-OE, should have cross-posted here) We're having a problem with 64-bit Java on our z/OS 1.12 (yeah, I know) system. To wit, the following all work: /u/Java14_31/J1.4/bin/javac -help /u/Java14_64/J1.4_64/bin/javac -help /u/Java5_31/J5.0/bin/javac -help /u/Java5_64/J5.0_64/

Re: CSA Shrank in DR

Thank you very much, all. You have been most helpful. I have run into this problem before so I need to spend more time on it. All of your suggestions and recommendations will help me get to the bottom of it. Much appreciated. On Fri, May 6, 2016 at 9:15 AM, Peter Relson wrote: > >DR:

Re: IBM secure z/OS software delivery: Don't get locked out!

On 5/6/2016 10:35 AM, vern wrote: All the doc's I can find seem to be pertinent to zOS 2.1 or 2.2 . We're still running 1.13, can we get the secure retrieval working on that ? If you don't have z/OS Security Level 3, then you won't be able to use FTPS to download IBM products and PTFs. Howeve

Re: z10BC Mainframe Available in Connecticut for *Your* Basement

W dniu 2016-05-06 o 16:55, Timothy Sipples pisze: [...] This particular machine is configured with 32 GB of memory, so it's quite realistic to run multiple LPARs. Well... I had 64GB on my z10, but ran 13 LPARs concurrently (2 productions) , so yes, it's quite possible to run mupltiple LPARs on

Re: Using TYPE=MEMORY (or VIO?)

I didn't know it was so simple. Thought I would have to dig into ACS routines. So ISMF tells me this: STORGRP SGVIO VIO NAME TYPE MAXSIZE UNIT --(2)--- ---(3)-- --(4)-- (5)- VIODAVIO 13500 3390 Compared with Ed, we have a

Re: zSECURE 32 x 80 Hang

I've remembered a little more about session hang and MTU size. 1500 is supposed to work everywhere, however there are some things in the past that just didn't work with 1500, and the symptom was that things just quietly hung. Some times it would even paint part of the screen and hang. Changin

Re: Mounting Unique zFS for SMPE APPLY

On Fri, 6 May 2016 19:42:05 +0200, Lucas Rosalen wrote: >ADRDSSU copy with RENAME and either DDDEF update on SMPE or DD statement in >JCL will do the trick. > Doesn't SMP/E employ UNIX pathnames rather than DFSMF data set names, making it harder to trick. Copy; update; copy back. Ouch! And the

Re: zSECURE 32 x 80 Hang

George Henke wrote: >Whenever we Dial into our z/OS VM with PCOMM and 32X80 screen size it hangs at >the very end of the ISPF dialog and after displaying the final ISPF dialog >screen. What do you mean by 'hang'? Are your sessions standing still, waiting for something requiring a cancel of you

Re: Using TYPE=MEMORY (or VIO?)

On 5/6/2016 10:30 AM, Jesse 1 Robinson wrote: Like John, we probably have some ACS limits on VIO that I'm not privy to. I seriously doubt there are any SMS VIO limits to which you are not privy. If you can issue MVS commands, you can do something like this (using my systems as example): D

Re: zSECURE 32 x 80 Hang

Dial in? Really? Rob Schramm On Fri, May 6, 2016, 1:40 PM George Henke wrote: > Whenever we Dial into our z/OS VM with PCOMM and 32X80 screen size it hangs > at the very end of the ISPF dialog and after displaying the final ISPF > dialog screen. > > 24 X 80 is ok. > > Coming through PCOMM on C

Re: zSECURE 32 x 80 Hang

Check MTU sizes. It's been so long ago, I don't remember why. Len Rugen University of Missouri Division of Information Technology Systems & Operations - Metrics & Automation Team From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behal

Re: OMVS hang at system shutdown

Tom and I have always agreed on this subject. We've hammered on our automation product vendors (Candle/IBM) to provide for each task an option to bring down it or not. Some tasks should come down clean; for others it could not matter. The problem is that until all tasks managed by automation are

Re: Mounting Unique zFS for SMPE APPLY

We maintain a complete set of zFS files for OMVS with hlq that matches the z/OS level: OSR13, OSR21, etc. These are permanent and always mounted for the life of the OS release. To create production copies--we need seven--we DSS dump/restore the 'service' files with names appropriate for producti

Re: Mounting Unique zFS for SMPE APPLY

ADRDSSU copy with RENAME and either DDDEF update on SMPE or DD statement in JCL will do the trick. However, this could (and should?) be "automated" somehow, for example by using SYSRES name as part of the dataset name, thus using &SYSR1 symbol in BPXPRMxx. Regards, Lucas On May 6, 2016 19:23, "Geo

Re: Mounting Unique zFS for SMPE APPLY

My service is always applied to a unique set of zfs's. This is then copied w/rename to produce the SYSRES vols. In my case, the suffix is unique. The SMP verisons of the datasets are hlq.unique.z* The "real" versions of the datasets are hlq.unique.t* The SMP/E (hlq.unique.z*) are pointed to on a

zSECURE 32 x 80 Hang

Whenever we Dial into our z/OS VM with PCOMM and 32X80 screen size it hangs at the very end of the ISPF dialog and after displaying the final ISPF dialog screen. 24 X 80 is ok. Coming through PCOMM on CITRIX is ok. Coming through a NATed address in PCOMM is also ok. It only fails when we Dial I

Re: OMVS hang at system shutdown

I'm with you... It seems like operators are often told that D A,L should come back with nothing before V XCF. Of course we want to get tasks with databases shutdown nicely (CICS, DB2, etc.), and files closed (bpxoinit shutdown) and checkpoint records written ($PJES2 or even $PJES2,TERM) but w

Re: Using TYPE=MEMORY (or VIO?)

I misspoke. VIO goes to virtual storage, which is central as available and eventually to AUX if need be. Like John, we probably have some ACS limits on VIO that I'm not privy to. For sure 'UNIT=VIO' gets a JCL error here because that esoteric is not defined in the IODF. I don't do C, so I'm no

Mounting Unique zFS for SMPE APPLY

The zFS names on our SMPE maintenance system are the same as on the PROD RES VOLS. How do you make them unique so they can be mounted on the SMPE maintenance system for the SMPE APPLYs? I suppose just DSS copy and rename them to something else? -- George Henke (C) 845 401 5614

Re: Storage Increment

Probably the definitive place to check is in the "PR/SM Planning Guide". The z13 one is SB10-7162, and the relevant section is "Storage Configurations" -> "Central Storage" where it lists the storage granularity (page 96 in the latest version). It agrees with the previous answers :-) Geoff Rou

Re: Using TYPE=MEMORY (or VIO?)

Paging space or memory? VIO can go to Central Storage - if you have some. I suspect you don't. :-( Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Cloud & Systems Performance, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: Marti

Re: Using TYPE=MEMORY (or VIO?)

On Fri, May 6, 2016 at 12:00 PM, Jesse 1 Robinson wrote: > After stating flatly that we do not support VIO, I ran a test and learned > otherwise. For sure we do not support the esoteric name 'VIO'. In my > previous shop IIRC it was implemented as 'SYSVIO'. I don't know why the > name change, but

Re: Using TYPE=MEMORY (or VIO?)

After stating flatly that we do not support VIO, I ran a test and learned otherwise. For sure we do not support the esoteric name 'VIO'. In my previous shop IIRC it was implemented as 'SYSVIO'. I don't know why the name change, but I would guess it's to avoid canned jobs from gobbling up paging

Re: How expensive is AMODE switching?

Well, DUH! I'll look at the code and see if that's feasible. -- Jerry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Using TYPE=MEMORY (or VIO?)

On 2016-05-06, at 09:35, Jesse 1 Robinson wrote: > > ... , be aware that some customers (like us) did away with VIO a long time > ago. > Did they tend to preserve their VIO esoteric name? Could you even count on the same esoteric name's existing even in all shops supporting VIO? I sometimes

Re: Using TYPE=MEMORY

Jesse and John, Thanks guys, Jesse , your right and I wouldnt want to impose that on a customer. Since we deal with IDM stuff, Identity Management , we are sensitive to customers...man are we . Regards, Scott On Fri, May 6, 2016 at 11:44 AM, John McKown wrote: > On Fri, May 6, 2016 at 10:03 AM

Re: z10BC Mainframe Available in Connecticut for *Your* Basement

According to his Reddit post, he paid $237 for it. At the Share presentation, he indicated there wasn't any noticeable increase in his parents electric bill. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of michelbutz Sent: Friday, Ma

Re: Using TYPE=MEMORY

On Fri, May 6, 2016 at 10:03 AM, Scott Ford wrote: > All, > > I need to know or where to find, can a z/OS batch job or STC calling a C > routine write output to a TYPE=MEMORY file. I am trying to eliminate the > usage of a real file. The application is time sensitive and handles > sensitive data.

Re: Using TYPE=MEMORY

This sounds like a job for VIO, which is in effect a memory-only file. As discussed recently, VIO is appropriate only for small temporary files since it uses the paging subsystem. However, if your solution will end up in a commercial product, be aware that some customers (like us) did away with

Re: Storage Increment

(I had forgotten about the role of total installed memory.) If you have two processors side by side with different increment sizes, remember that one box allows you to be more granular than the other. It's not a bad thing as long as you don't calculate an 'optimal size' that only one box can ach

Re: z10BC Mainframe Available in Connecticut for *Your* Basement

I didn't catch the initial e-mail thread what did he pay and what is his monthly electrical bill Sent from my iPhone > On May 6, 2016, at 10:55 AM, Timothy Sipples wrote: > > For those of you who would like to attempt to recreate Connor's feat, > especially if you have understanding parents,

Using TYPE=MEMORY

All, I need to know or where to find, can a z/OS batch job or STC calling a C routine write output to a TYPE=MEMORY file. I am trying to eliminate the usage of a real file. The application is time sensitive and handles sensitive data. All comments and suggestions are appreciated. Scott IDMWORKS

z10BC Mainframe Available in Connecticut for *Your* Basement

For those of you who would like to attempt to recreate Connor's feat, especially if you have understanding parents, you may wish to consider this auction: https://www.govdeals.com/index.cfm?fa=Main.Item&itemid=452&acctid=3678 This z10BC machine is two model generations newer than Connor's z890 ma

Re: How expensive is AMODE switching?

On 5/6/2016 7:24 AM, Jerry Callen wrote: There is a short segment of 31-bit code that is generated on the fly by another piece of software that I need to call. I don't control that piece of software, and I'm putting the results of that computation into an above-the-bar chunk of memory for late

Re: How expensive is AMODE switching?

On Fri, May 6, 2016 at 9:24 AM, Jerry Callen wrote: > There is a short segment of 31-bit code that is generated on the fly by > another piece of software that I need to call. I don't control that piece > of software, and I'm putting the results of that computation into an > above-the-bar chunk of

Re: How expensive is AMODE switching?

There is a short segment of 31-bit code that is generated on the fly by another piece of software that I need to call. I don't control that piece of software, and I'm putting the results of that computation into an above-the-bar chunk of memory for later processing. No I/O. Since it sounds as

Re: OMVS hang at system shutdown

Why even bother shutting it down? We do the following as one of that last few things, before doing the V XCF command. F bpxoinit,shutdown=forks F bpxoinit,shutdown=filesys And call it good. _ Dave Jousma Assistant Vice President,

Re: OMVS hang at system shutdown

On 5/6/2016 8:47 AM, Styles, Andy , SD EP zPlatform wrote: On Fri 06/05/2016 at 13:14, Tom Conley wrote: *BPXI056E OMVS SHUTDOWN REQUEST HAS COMPLETED SUCCESSFULLY (why is that an 'E' level message?) "E" here is not "ERROR", it's "Eventual Action", which is the "F OMVS,RESTART" command.

Re: OMVS hang at system shutdown

I have seen this occur: 1) waiting to transfer ownership of the file system to the "surviving' (LPAR(s)). You might check the automove status of your file systems. 2) health checker is usually very slow in shutting down 3) HIS You might try adding f omvs,stoppfs=zfs(? on the syntax) earlier in

Re: CSA Shrank in DR

>DR: SQA 988KCSA 3.43M >Prod:SQA 1.11MCSA 4.28M Did you mean that the size of CSA shrank or the amount of CSA being used shrank? I think some of the posts thought it was the former, but the above makes me think it's the latter.

Re: OMVS hang at system shutdown

On Fri 06/05/2016 at 13:14, Tom Conley wrote: >> *BPXI056E OMVS SHUTDOWN REQUEST HAS COMPLETED SUCCESSFULLY >> >> (why is that an 'E' level message?) >> > > "E" here is not "ERROR", it's "Eventual Action", which is the "F > OMVS,RESTART" command. Ah! Of course - I'd forgotten IBM use the same su

Re: CSA Shrank in DR

On Thu, 5 May 2016 14:22:23 -0500, John McKown wrote: >On Thu, May 5, 2016 at 2:07 PM, phil yogendran wrote: > >> We recently performed a DR exercise and on one of the LPAR's, the CSA was >> smaller by about 800k. Parmlib specification in DR and production were >> identical. The LPAR affected is o

Re: Storage Increment

Thank you all, your responses were exactly what I was looking for. I did parse the technical guide but was looking for 'storage increment size'. You have shown me that I need to take a much closer look at the manual. FYI, we will have 2 processors with 256G and the other with 128G. So, according t

Re: CSA Shrank in DR

On Thu, May 5, 2016 at 3:12 PM, phil yogendran wrote: > I did think it was a bigger IODF but in my case SQA in DR has gone down > implying a smaller IODF. However, CSA has also gone down. Here's some > inform from DR and Prod; > > DR: SQA 988KCSA 3.43M > > Prod:

Re: OMVS hang at system shutdown

On 5/6/2016 3:42 AM, Styles, Andy , SD EP zPlatform wrote: Morning all, We have noticed an intermittent OMVS shutdown problem, possibly since going to z/OS 2.1, though I'm not willing to bet on that. The general scenario is that almost all of the system is down, and we're into stopping OMVS.

Re: Storage Increment

You can also find the storage increment value in field SCCBSAI, or in field SCCBSAIX if SCCBSAI contains zero. The SCCB is pointed to by the CVT. On Thu, 5 May 2016 14:49:04 -0400, phil yogendran wrote: >Hello, > >We currently have 3 processors where 2 have a storage increment size of 256 >and

Re: Storage Increment

W dniu 2016-05-06 o 04:52, phil yogendran pisze: Thanks but where is that documented? How can I tell beforehand that my z13 model 123 will have an increments size of xyz? It is determined by hardware and it depends on installed/assigned memory. So, it is not enough to say "z13". You have to kn

Re: Storage Increment

The Technical Guide Redbooks for the relevant processor typically has this. Might be in the planning guide too. Looks like minimum granularity for the z13 is 512MB. Scott On Thu, 5 May 2016 22:52:19 -0400, phil yogendran wrote: >Thanks but where is that documented? How can I tell beforehand t

WINHLL emulator api support for windows 64

All, I have always been working on IBM supplied (and other emulator versions of) whllapi.dll Recently my windows got upgraded to 64 bit and i am no more able to run the old macros. When i checked IBM documentation i found that older 32 bit dlls may not work. Windows x64 Platform Support

Re: OMVS hang at system shutdown

Styles, Andy wrote: >Any D OMVS command appears to simply result in OMVS saying 'I told you, I'm >shutting down' and nothing more. Very frustrating. Indeed. But to wait 20 min is way too long [0] if you have a fast and furious machine. Ask the automation to issue all those D OMVS,... [1] and

Re: OMVS hang at system shutdown

Well, at the point we're shutting OMVS down, JES2 has already gone, and there are relatively very few address spaces left. This is an example: D A,L IEE114I 10.57.40 2016.126 ACTIVITY 726 JOBS

Re: OMVS hang at system shutdown

Styles, Andy wrote: >*BPXI056E OMVS SHUTDOWN REQUEST HAS COMPLETED SUCCESSFULLY > (why is that an 'E' level message?) Good catch! > ... Obviously the thing to do here is take a dump and open a PMR, but we > haven't yet seen the issue since we decided to do that. I just wondered > whether

OMVS hang at system shutdown

Morning all, We have noticed an intermittent OMVS shutdown problem, possibly since going to z/OS 2.1, though I'm not willing to bet on that. The general scenario is that almost all of the system is down, and we're into stopping OMVS. Systems automation then issues a stop to OMVS: F OMVS,SHUT

Re: Getting timely dump out of LE

I too have a large C and ASM LE application and I use TRAP(OFF,NOSPIE). That gets you an immediate dump on the first 0C4 and then you can use the IPCS command VERBX LEDATA 'TCB() CEEDUMP' to get the LE trace-back, which is useful if the abend was in C code. Robin -Original Message-