z13s information

https://www-03.ibm.com/systems/z/hardware/z13s.html לשימת לבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה קשורה שלה (להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה,

IBM z13s article.

http://www.pcworld.com/article/3033464/ibm-unveils-z13s-mainframe-focused-on-security-and-hybrid-clouds.html N10 with 1TB or N20 with 4TB. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all?

Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

Did you oonsider responding with an automation tool and save your fingers? this is a well defined case where automation can help... ITschak ITschak Mugzach Z/OS, ISV Products and Application Security & Risk Assessments Professional On Mon, Feb 15, 2016 at 10:30 PM, Joe Aulph

Re: Query: Will modern z/OS and z/VM classes suffice for MVS and VM/370

I heavily recommend signing up for the Hercules yahoo groups for installing VM/370, MVS 3.8, DOS/VS, Music, PDOS, MVT 21.8F with APL\360, etc. Yes, they have been working on emulators, but using these versions of software. They even have install tape images and scripts to load empty volumes.

Re: Query: Will modern z/OS and z/VM classes suffice for MVS and VM/370

On 16Feb15:1842-0800, Anne & Lynn Wheeler wrote: > vast majority of 4341s were shipped with FBA disks ... you would need > some sort of CKD disks in order to bring up MVS. > > huge percentage of 4341s went out into departmental areas with 3370 FBA > disks, sort of leading edge of distributed

Re: SMPE: Un-ACCEPTing USERMOD

Hi, Thanks for the responses. The ACCEPT occurred by accident (I am assuming) in 2013. Haven't fully scoped if I can recreate the whole DLIB zone from scratch, but my expectation is low probability of success due missing MCS. The "canned" dialog will not permit generation of ACCEPT code these

Re: Query: Will modern z/OS and z/VM classes suffice for MVS and VM/370

ri...@livingcomputermuseum.org (Rich Alderson) writes: > We are currently in the process of restoring a 4341 to operating > condition. We have just last week corrected a fault in the power > system, and are able to power the system up and IML it from floppy. > > We are now deciding what operating

Re: Query: Will modern z/OS and z/VM classes suffice for MVS and VM/370

On 15 Feb 2016 18:24:12 -0800, in bit.listserv.ibm-main you wrote: >We are currently in the process of restoring a 4341 to operating condition. >We have just last week corrected a fault in the power system, and are able to >power the system up and IML it from floppy. > >We are now deciding

Query: Will modern z/OS and z/VM classes suffice for MVS and VM/370

We are currently in the process of restoring a 4341 to operating condition. We have just last week corrected a fault in the power system, and are able to power the system up and IML it from floppy. We are now deciding what operating system to run on the restored system. Most likely, we will

Default overrides for binder?

The assembler has the ASMAOPT macro to build the ASMADOPT CSECT containing the shop defaults for HLASM. COBOL has the IGYCOPT macro to build the IGYCDOPT CSECT containing the shop defaults for COBOL. There does not appear to be anything similar for the binder. Am I overlooking it? (I know

Re: Reading the CA-1 Tape Catalog

The BUFNO= is only needed if you did _not_ increase the block size of your TMC (available in latest releases, along with other improvements to the TMC including uptime improvements like allowing online extension of a TMC in use by multiple systems.. Thanks, CA! - I'm retired and only

Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

In previous and current assignments I have, in test, destroyed a DB and attempted an IPL, after 45 minutes of bleeding-finger console responses we gave up and IPL'd off a good DB. We have forced the DB offline, fail soft testing, and after 50-70 console responses were able to get 1 TSO user logged

Re: Would ISGQUERY be the proper Service

Thanks Leo, -- Original Message -- From: Leonardo Vaz To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Would ISGQUERY be the proper Service Date: Mon, 15 Feb 2016 16:21:12 + ISGQUERY should work for what you are attempting, the following simple test worked fine

Re: Issues with VSAM Enqueuers and Batch job with IDCAMS

I think Lizette said the problem is fleeting. By the time you know you have the problem ... it's gone. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pinnacle Sent: Monday, February 15, 2016 10:50 AM To:

Re: Issues with VSAM Enqueuers and Batch job with IDCAMS

On 2/15/2016 11:52 AM, Lizette Koehler wrote: I have an issue where an STC holds a VSAM Dataset. The STC is a scheduling software that writes all of the info on jobs running/completed/failed and so forth, to this file. Once per day we close and free the VSAM file from the STC, run an archive

Re: Issues with VSAM Enqueuers and Batch job with IDCAMS

On a completely different tack: What if you defined the VSAM file as ESDS, and used an AIX and PATH? Would you still need to sort the data? Would this give you the speed and efficiency you need and possibly solve this issue? The only splits you would get would be in the AIX. And you could

Re: Issues with VSAM Enqueuers and Batch job with IDCAMS

Ok, so you are doing a REPRO ODS, not OFILE, like you had stated, I would try to have the VSAM file allocated with DISP=OLD and doing the repro OFILE, I believe that should guarantee you don't get the "DATASET IN USE BY ANOTHER TASK" message. Considering you free the dataset from the CICS

Re: Issues with VSAM Enqueuers and Batch job with IDCAMS

So, the step previous is a DFSORT Step. Then the IDCAMS REPRO step The SYSS.HISTTEMP.BKUP is the data that will be reloaded back into the SYSS.HISTFILE. The sort step is just to put the records in correct sequence before reloading. //STEP1G EXEC PGM=SORT,COND=(0,LT)

Re: Issues with VSAM Enqueuers and Batch job with IDCAMS

How is that VSAM file allocated on your repro step? DISP=OLD or DISP=SHR? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, February 15, 2016 11:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Issues with VSAM

Re: Issues with VSAM Enqueuers and Batch job with IDCAMS

If you only use the dataset for two things, and right after the first completes the second fails, the ENQ might not have cleared when the second starts. How about an IEFBR14 with a DD for the dataset at the start of the STC task. On Mon, Feb 15, 2016 at 10:52 AM, Lizette Koehler

Issues with VSAM Enqueuers and Batch job with IDCAMS

I have an issue where an STC holds a VSAM Dataset. The STC is a scheduling software that writes all of the info on jobs running/completed/failed and so forth, to this file. Once per day we close and free the VSAM file from the STC, run an archive process and then re-open then file to the STC.

Re: Manipulating system symbols

I would suggest they use the 3 character message prefix. On Mon, Feb 15, 2016 at 10:08 AM, Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 15 Feb 2016 03:33:36 -0600, Art Gutowski wrote: Please note that with z/OS 2.2 the length of system symbols names

Re: Would ISGQUERY be the proper Service

ISGQUERY should work for what you are attempting, the following simple test worked fine for me to show the first job enqueueing the dataset: OPEN (SYSPRINT,(OUTPUT)) STORAGE OBTAIN,ADDR=(R10),LENGTH=4096 ISGQUERY REQINFO=QSCAN,SCANACTION=START, X

Re: Manipulating system symbols

On Mon, 15 Feb 2016 03:33:36 -0600, Art Gutowski wrote: >>> >>> Please note that with z/OS 2.2 the length of system symbols names has >>> increased from 8 to 16, and may include the underscore character. >>> >>> -Original Message- >>> On Behalf Of Paul Gilmartin >>> Sent: Thursday, 4

Re: Would ISGQUERY be the proper Service

On Sun, 14 Feb 2016 16:25:19 -0800, Ed Jaffe wrote: >On 2/14/2016 2:01 PM, essteam wrote: >> Is ISGQUERY the proper macro/service to accomplish this ? > >ISGQUERY will give you information about ENQs and RESERVEs, including >the system names, job names, ASIDs, and TCB addresses of those holding

Re: Would ISGQUERY be the proper Service

On Mon, 15 Feb 2016 13:50:27 GMT, esst...@juno.com wrote: >Im not trying to free and allocate CICS. >I want to identify the current job that has a dataset allocated >when my STC needs it. However, if your concern is for a VSAM file then it sounds it's the share options that

Re: Real Storage Allocation

As long as your z/OS isn't running under, z/VM like may smaller ISVs, where LFAREA is not yet supported. John T. Abell Tel:800-295-7608Option 4 President International: 1-416-593-5578 Option 4 E-mail: john.ab...@intnlsoftwareproducts.com Fax:800-295-7609

Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

I would not want to run with such an MPF exit or AUTORxx member active in production. You can have it there for emergencies and activate it with a SET command. This keeps the pain level of failsoft mode a lot more tolerable. We used to have a couple of such exits waiting in the wings for

Re: Would ISGQUERY be the proper Service

My comment about - not everything is good to be done in CICS was the main reason to for the suggestion. If you put CICS in a wait state while an MVS function goes off and "does something", then all of CICS waits. So, you should be wary when using come functions that are easily done in MVS but

Re: Would ISGQUERY be the proper Service

Thank You The "WHO' Command is exactly what Im looking for ONLY it needs to be issued from the CICS OPEN/CLOSE exit routine. Thaks -- Original Message -- From: Peter Relson To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Would ISGQUERY be the proper Service Date:

Re: Would ISGQUERY be the proper Service

Im not trying to free and allocate CICS. I want to identify the current job that has a dataset allocated when my STC needs it. -- Original Message -- From: Lizette Koehler To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Would ISGQUERY be the proper Service

Re: Would ISGQUERY be the proper Service

On Mon, Feb 15, 2016 at 6:43 AM, Peter Relson wrote: > >ISGQUERY will give you information about ENQs and RESERVEs... > >It has nothing to do with OPEN/CLOSE. > > True, but there is a strong correlation between OPEN and Allocate and the > SYSDSN ENQ that usually accompanies

Re: UADS (was Re: [Bulk] Re: COBOL v5)

... On 01-Feb-2016 9:57 PM, "John Eells" wrote: > I hadn't really thought about (or researched) the display capabilities of > RACF. An RFE couldn't hurt if you find them lacking. > > Once one's TSO/E administrative routines have been converted to use the > TSO segment, though,

Re: UADS (was Re: [Bulk] Re: COBOL v5)

.. On 01-Feb-2016 9:57 PM, "John Eells" wrote: > I hadn't really thought about (or researched) the display capabilities of > RACF. An RFE couldn't hurt if you find them lacking. > > Once one's TSO/E administrative routines have been converted to use the > TSO segment, though,

Re: Would ISGQUERY be the proper Service

>ISGQUERY will give you information about ENQs and RESERVEs... >It has nothing to do with OPEN/CLOSE. True, but there is a strong correlation between OPEN and Allocate and the SYSDSN ENQ that usually accompanies the allocation. So I think of the OP's request as querying the SYSDSN ENQ for the

Re: [Bulk] Re: [Bulk] UADS (was Re: [Bulk] Re: COBOL v5)

I wholeheartedly agree with Joel's recommendation for having a backup copy of the RACF database readily available for recovery. I just want to add that it is crucial to use RACF utilities to create the backup and to allocate it with the proper characteristics. The preferred utility to use to

Re: Manipulating system symbols

On Wed, 3 Feb 2016 19:53:48 -0800, Skip Robinson wrote: >Sweet. Did not pick up on that. All the more reason to prefix symbols with a >unique string. > >> -Original Message- >> On Behalf Of Anthony Thompson >> Sent: Wednesday, February 3, 2016 07:48 PM >> >>

Re: Catalog VVDS confusion

On Fri, 5 Feb 2016 11:54:37 -0600, Tom Marchant wrote: >Many years ago, I had a colleague run REPOR MERGECAT as a way of creating a >backup >copy of some catalogs. I didn't notice the caution in the manual that says >that the old >catalog should not be used to