Archive for category Storage
Batch Job to delete a specific member of a Partitioned dataset
Posted by Rui Miguel Feio in JCL, MVS, Storage, Tech - Mainframe on April 3, 2013
If you come across the need to delete a specific member of a Partitioned dataset and you want to do it via batch job, then you can use IDCAMS for the effect:
//DELETE EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
DELETE USER1.PDS.EXAMPLE(MEMBER1)
In the above example member MEMBER1 of the partitioned dataset USER1.PDS.EXAMPLE will be deleted.
Batch Job to delete all members of a Partitioned dataset
Posted by Rui Miguel Feio in JCL, MVS, Storage, Tech - Mainframe on April 3, 2013
Here’s a simple way of deleting all members of a partitioned dataset via a batch job:
//DELETE EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
DELETE USER1.PDS.EXAMPLE(*)
In the above example all the members (represented by the *) of the dataset USER1.PDS.EXAMPLE will be deleted.
Useful Operator Commands
Posted by Rui Miguel Feio in JES, MVS, Storage, Tech - Mainframe, USS on April 4, 2012
| MVS Commands | |
|---|---|
| d a,l | All active Address spaces |
| d a,xy* | Active jobs starting with “XY” |
| d parmlib | PARMLIB concatenation |
| d prog,lnklst | Programs defined to Link List |
| d asm,page=all | Page data sets & utilization of page space |
| d etr | Sysplex timer |
| d grs,c | Global resource serialization – contention |
| d iplinfo | IPL time & bootstrap parms |
| d m=cpu | Status of logical processors in the LPAR image |
| d m | Matrix of entire image configuration |
| d m=stor | Number of bytes of storage the system owns |
| d m=dev | Status for devices |
| d wlm,ird | Status of IRD features used |
| d wlm,systems | Systems in Goal Mode |
| d wlm,applenv=* | Which Application Environments are active |
| d j,all | All jobs running on the system |
| d logger,l | Logger Log Streams |
| d parmlib | PARMLIB data sets used for this IPL |
| d omvs,a=all | zOS UNIX address space processes |
| d omvs,f | HFS file systems currently in use or mounted |
| d omvs,o | zOS Unix current configuration setting |
| d omvs,p | PFS (physical file system) configuration information |
| d omvs,waiters | What Unix threads are waiting on |
| d omvs,sockets | UNIX Sockets |
| d a,bpxas | All spwaned and forked initiator BPXAS address spaces |
| d opdata | Operator Command Prefixes (subsystem’s recognition characters) |
| d r,l | Outstanding WTORs (Write To Operator withReplys) |
| d smf | SMF recording dataset status |
| d symbols | System symbolics |
| d tcpip,,n,portl | TCP/IP ports being listened on |
| d tcpip,,n,routes | TCP/IP routes |
| d tcpip,,n,home | TCP/IP Home |
| v tcpip,,o,sys1.tcpparms(profilex) | Refresh TCP/IP Profile parms |
| d prog,apf | List all authorized programs |
| d trace | All trace settings |
| d u | Track device allocations |
| d u,dasd,online,,99 | Online DASD devices |
| d xcf,cpl | XCF parameters and coupled data sets |
| d xcf,str | All structures in coupling facility and their type |
| d xcf,cf,cfnm=all | All connections to coupling facility |
| d xcf,policy,type=cfrm | Coupling Facility Policy |
| JES2 Displays | |
| $dspl | JES2 Spool utilization (note the “$” prefix for JES2 commands) |
| $t spooldef | JES2 spool characteristics |
| $d perfdata | JES2 statistics |
| $d a | All active JES Jobs |
| $d srvclass | JES2 targets how many initiators are started in each service class |
VSAM Open Error Codes
Posted by Rui Miguel Feio in MVS, Storage, Tech - Mainframe on December 24, 2011
| 136(88) | Not enough Virtual-Storage Space is available for Work Areas, Control Blocks, or Buffers. |
| 144(90) | An uncorrectable I/O error occurred while VSAM was Reading or Writing a catalog record. |
| 148(94) | No record for the data set to be opened was found in the available catalog(s) or an unidentified error occurred while VSAM was searching the catalog. |
| 152(98) | Security Verification failed; the password specified in the Access-Method Control Block for a specified level of access does not match the password in the catalog for that level of access. |
| 164(A4) | An uncorrectable I/O error occurred while VSAM was Reading the Volume Label. |
| 168(A8) | The data set is not available for the type of processing you specify, or an attempt was made to open a Reusable data set with the Reset option while another user had the data set. |
| 176(B0) | An error occurred while VSAM was attempting to fix a page of Virtual storage in Real storage. |
| 180(B4) | A VSAM catalog specified in JCL either does not exist or is not open, and no record for the data set to be opened was found in any other catalog. |
| 184(B8) | An uncorrectable I/O error occurred while VSAM was completing an I/O request. |
| 188(BC) | The data set indicated by the Access-Method Control Block is not of the type that may be specified by an Access-Method Control Block. |
| 192(C0) | An unusable data set was opened for output. |
| 232(E8) | Reset was specified for a nonreusable data set and the data set is not empty. |
| 236(EC) | A permanent Staging error occurred in MSS (Acquire). |
| 244(F4) | The Volume containing the Catalog Recovery area was not mounted and verified for output processing. |
VSAM Logical Error Codes
Posted by Rui Miguel Feio in MVS, Storage, Tech - Mainframe on December 11, 2011
| 004(04) | Read past end of file |
| 008(08) | You attempted to store a record with a Duplicate Key, or there is a duplicate record for an alternate index with the unique key option. |
| 012(0C) | You attempted to store a record out of Ascending Key Sequence in Skip-Sequential Mode; record had a Duplicate Key; for Skip-Sequential processing your GET, PUT, and POINT Requests are not referencing records in Ascending Sequence; or, for Skip-Sequential Retrieval, the key requested is lower than the previous key requested. For Shared Resources, buffer pool is full. |
| 016(10) | Record not found. |
| 020(14) | Record already held in exclusive control by another requester. |
| 024(18) | Record resides on a volume that cannot be mounted. |
| 028(1C) | Data set cannot be extended because VSAM can’t allocate additional Direct-Access Storage Space. Either there is not enough space left to make the secondary allocation or you attempted to increase the size of a data set while processing SHROPT=4 and DISP=SHR. |
| 036(24) | KeyRangeswere specified for the data set when it was defined but no range was specified that includes the record to be inserted. |
| 040(28) | Insufficient Virtual Storage to complete the request. 044(2A) Work area too small. 064(40) All available strings are in use. |
| 068(44) | You attempted to use a type of processing (Output or Control-Interval Processing) that was not specified when the data set was opened. |
| 074(4A) | Trying to use keys on ESDS or RRDS. |
| 076(4C) | You issued an Addressed or Control-Interval PUT to add to a Key-Sequenced data set, or issued a Control-Interval put to a Relative Record data set. |
| 080(50) | Trying to delete from ESDS. |
| 084(54) | Using OPTCODE=LOC for a PUT. |
| 088(58) | You issued a Sequential GET request without having caused VSAM to be positioned for it, or you changed from Addressed Access to Keyed Access without causing VSAM to be positioned for Keyed- Sequential Retrieval; there was no Sequential PUT insert for a Relative Record data set, or you attempted an illegal switch between forward and backward processing. |
| 92(5C) | A PUT for update or an ERASE was issued without a previous GET for update, or a PUTIX was issued without a previous GETIX. |
| 96(60) | Changing the Prime Key or Key of Reference when making an update. 100(64 Trying to change record length. |
| 104(68) | The RPL options are either invalid or conflicting. 108(6C) RECLEN specified was larger than the maximum allowed, equal to 0, or smaller than the sum of the length and the displacement of the key field; RECLEN was not equal to record (SLOT) size specified for a Relative Record data set. |
| 112(70) | Invalid key length. |
| 116(74) | Trying to update an empty dataset. |
| 120(78) | Request was submitted by the wrong task. 132(84) An attempt was made in Locate Mode to retrieve a Spanned Record. |
| 136(88) | You attempted an Addressed GET of a Spanned record in a Key- Sequenced data set. |
| 140(8C) | Inconsistent Spanned record. |
| 144(90) | Invalid pointer (no associated base record) in an Alternate Index. |
| 148(94) | Maximum number of Alternate Index pointers exceeded. |
| 152(98) | Not enough buffers available. |
| 156(9C) | Invalid control interval. |
| 192(C0) | Invalid Relative Record number in a RRDS dataset. |
| 196(C4) | Addressed access to a Relative Record (RRDS) dataset is not allowed. |
| 200(C8) | Addressed Access or Generic Backward processing by Key thru a path is not allowed. |
| 204(CC) | Attempting a PUT in backward mode. |
| 252(FC) | Record mode processing is not allowed for a Linear data set. |
VTOC (Volume Table of Contents)
Posted by Rui Miguel Feio in Glossary, MVS, Storage, Tech - Mainframe on December 2, 2010
z/OS uses a Catalog and a Volume Table of Contents (VTOC) on each DASD to manage the storage and placement of data sets
The VTOC lists the data sets that reside on its volume, along with information about the location and size of each data set, and other data set attributes.
A standard z/OS utility program, ICKDSF, is used to create the label and VTOC. When a disk volume is initialized with ICKDSF, the owner can specify the location and size of the VTOC. The size can be quite variable, ranging from a few tracks to perhaps 100 tracks, depending on the expected use of the volume. More data sets on the disk volume require more space in the VTOC.
The VTOC also has entries for all the free space on the volume. Allocating space for a data set causes system routines to examine the free space records, update them, and create a new VTOC entry.
Data sets are always an integral number of tracks (or cylinders) and start at the beginning of a track (or cylinder).
You can also create a VTOC with an index. The VTOC index is actually a data set with the name SYS1.VTOCIX.volser, which has entries arranged alphabetically by data set name with pointers to the VTOC entries. It also has bitmaps of the free space on the volume.
A VTOC index allows the user to find the data set much faster.
Swapping
Posted by Rui Miguel Feio in Glossary, Storage, Tech - Mainframe on October 30, 2010
Swapping is the process of transferring all of the pages of an address space between real storage and auxiliary storage. A swapped-in address space is active; having pages in real storage frames and pages in auxiliary storage slots. A swapped-out address space is inactive; the address space resides on auxiliary storage and cannot execute until it is swapped in.
While only a subset of the address space’s pages (known as its working set) would likely be in real storage at any time, swapping effectively moves the entire address space. It is one of several methods that z/OS uses to balance the system workload and ensure that an adequate supply of available real storage frames is maintained.
Swapping is performed by the System Resource Manager (SRM) component, in response to recommendations from the Workload Manager (WLM) component.
The Paging Process
Posted by Rui Miguel Feio in MVS, Storage, Tech - Mainframe on October 29, 2010
In addition to the DAT hardware and the segment and page tables required for address translation, paging activity involves a number of system components to handle the movement of pages and several additional tables to keep track of the most current version of each page.
To understand how paging works, assume that DAT encounters an invalid page table entry during address translation, indicating that a page is required that is not in a real storage frame. To resolve this page fault, the system must bring the page in from auxiliary storage. First, however, it must locate an available real storage frame. If none are available, the request must be saved and an assigned frame freed. To free a frame, the system copies its contents to auxiliary storage and marks its corresponding page table entry as invalid. This operation is called a page-out.
After a frame is located for the required page, the contents of the page are copied from auxiliary storage to real storage and the page table invalid bit is set off. This operation is called a page-in.
Paging can also take place when z/OS loads an entire program into virtual storage. z/OS obtains virtual storage for the user program, and allocates a real storage frame to each page. Each page is then active and subject to the normal paging activity; that is, the most active pages are retained in real storage while the pages not currently active might be paged out to auxiliary storage.
Page stealing
z/OS tries to keep an adequate supply of available real storage frames on hand. When a program refers to a page that is not in real storage, z/OS uses a real storage page frame from a supply of available frames.
When this supply becomes low, z/OS uses page stealing to replenish it, that is, it takes a frame assigned to an active user and makes it available for other work. The decision to steal a particular page is based on the activity history of each page currently residing in a real storage frame. Pages that have not been active for a relatively long time are good candidates for page stealing.
Unreferenced interval count
z/OS uses a sophisticated paging algorithm to efficiently manage virtual storage based on which pages were most recently used. An unreferenced interval count indicates how long it has been since a program referenced the page. At regular intervals, the system checks the reference bit for each page frame. If the reference bit is off — that is, the frame has not been referenced — the system adds to the frame’s unreferenced interval count. It adds the number of seconds since this address space last had the reference count checked. If the reference bit is on, the frame has been referenced and the system turns it off and sets the unreferenced interval count for the frame to zero. Those frames with the highest unreferenced interval counts are those most likely to be stolen.
z/OS also uses various storage managers to keep track of all pages, frames, and slots in the system.
Frames, Pages and Slots
Posted by Rui Miguel Feio in Glossary, MVS, Storage, Tech - Mainframe on October 29, 2010
When a program is selected for execution, the system brings it into virtual storage, divides it into pages of 4 kilobytes (4K), and transfers the pages into real storage for execution. To the programmer, the entire program appears to occupy contiguous space in storage at all times. Actually, not all pages of a program are necessarily in real storage, and the pages that are in real storage do not necessarily occupy contiguous space.
The pieces of a program executing in virtual storage must be moved between real and auxiliary storage. To allow this, z/OS manages storage in units, or blocks, of 4 kilobytes.
The following blocks are defined:
- A block of real storage is a frame.
- A block of virtual storage is a page.
- A block of auxiliary storage is a slot.
A page, a frame, and a slot are all the same size: 4096 bytes (4 kilobytes). An active virtual storage page resides in a real storage frame. A virtual storage page that becomes inactive resides in an auxiliary storage slot (in a paging data set).
Virtual Storage
Posted by Rui Miguel Feio in Glossary, Storage, Tech - Mainframe on October 28, 2010
Virtual Storage means that each running program can assume it has access to all of the storage defined by the architecture’s addressing scheme. The only limit is the number of bits in a storage address. This ability to use a large number of storage locations is important because a program may be long and complex, and both the program’s code and the data it requires must be in real storage for the processor to access them.
z/OS supports 64-bit long addresses, which allows a program to address up to 16 exabytes (18,446,744,073,709,600,000 bytes) of storage locations. In reality, the mainframe might have much less real storage installed. How much less depends on the model of CP and the system configuration.
To allow each user to act as though this much storage really exists in the computer system, z/OS keeps only the active portions of each program in real storage. The rest of the code and data is kept in files called Page Data Sets on Auxiliary Storage, which usually consists of a number of high-speed DASDs (Direct Access Storage Devices).
Virtual Storage is therefore a combination of Real and Auxiliary Storage. z/OS uses a system of tables and indexes to relate the Auxiliary Storage locations to Real Storage locations and keep track of the identity and authority of each program.
How does the operating system keep track of each program piece?
How does it know whether it is in real storage or auxiliary storage, and where?
It is important for z/OS professionals to understand how the operating system makes this happen.
Physical Storage is divided into areas, each the same size and accessible by a unique address. In Real Storage, these areas are called frames; in Auxiliary Storage, they are called slots.
Similarly, the operating system can divide a program into pieces the size of frames or slots and assign each piece a unique address. This arrangement allows the operating system to keep track of these pieces. In z/OS, the program pieces are called pages.
Pages are referenced by their virtual addresses and not by their real addresses. From the time a program enters the system until it completes, the virtual address of the page remains the same, regardless of whether the page is in Real Storage or Auxiliary Storage.
Each page consists of individual locations called bytes, each of which has a unique virtual address.
The use of Virtual Storage in z/OS means that only the pieces of a program that are currently active need to be in Real Storage at processing time. The inactive pieces are held in Auxiliary Storage.
Follow Me!