ISPF Panel Primer

Q. What is an ISPF Panel?

As a Mainframe Programmer, you constantly work with and use Software Tools such as File-Aid, Expeditor, Abend-Aid etc. which save time and key-strokes. At its heart, these software tools have a power-packed engine(the Main COBOL Program or even a REXX EXEC) that does all the processing. But, its not just the Main COBOL program that makes them special. These software-tools also have pretty good-looking GUI Screens, on which the user types the Input and sees the outputs. Thus, the GUI-Screens allow the the User to work with and use the Software-Tools interactively. GUI-Screens of an Application are called ISPF Panels. ISPF Panels look like Internet Web-pages. They have a Menu or Action-Bar in the top-portion. When you click on or select an action-bar item, a pull-down containing the choices appears. ISPF Panels have a Panel-Title. The Body of the Panel has the main contents of the Panel – Input and Output Fields. The Message-Area displays any messages, when you enter the wrong Inputs. The Command Area allows you to enter Commands like START 3.2.

Q. What is Dialog Tag Language(DTL)?

Dialog Tag Language(DTL) is used to write the source code for ISPF Panels, and windows that are displayed on Mainframes. What HTML is to Internet Web-Pages, DTL is to ISPF Pages. Behind the scenes, you must write Source-code in DTL, to develop an ISPF-Panel like the one you saw above. In fact, DTL and HTML are identical-twins, DTL also has tags like <panel> <p> etc. just like HTML. Tags provide markup(descriptive information), about how text in a file is to be interpreted, or presented.

Q. How do you code a Panel in DTL?

You use the <panel> tag to create a new ISPF Panel. You must enclose the contents of the panel inside <panel> start and </panel> end tags.   The name attribute assigns a name to the ISPF Panel. I have named my ISPF Panel TSTPAN01. You may also code name=*, to set the panel name same as the member-name. I also wanna a panel-title "Catalog Ordering System", look how I’ve added it below - Every panel has a width and depth, that define how large the panel would look. If you specify window=no, then the panel has a default size of 24 rows x 80 columns.

Q. How do you position the Cursor on the Panel?

The panel tag has attributes cursor, csrindex and csrpos. The cursor attribute is the easiest and simplest to go with. You can set the cursor attribute the the name of a <choice> or <selfld> tag. You may also set the cursor attribute to the DATAVAR value of a <chofld>, <dtafld> or a <lstcol> tag. You may also position the cursor at the command-area, by specifying cmdarea as the cursor-value. The code given below, is for a simple-panel with a choice field. Look how the cursor is positioned at the dest field.   When you actually DISPLAY the Panel TSTPAN01, this is what it looks like. DTL is a WYSWIG Language(What you see, is what you Get).

Q. How do you compile the DTL Source Code and see the Output?

The Mainframe does not understand the Source-code that you have written in DTL. So, you must first translate the DTL Source-Code into an ISPF Compatible form. The Compiler or Translator Software is called ISPDTLC. You can invoke ISPDTLC Compiler Software by typing ISPDTLC in the Command-Area.   I have written the DTL Source-Code in a Member TSTPAN01 which resides under the library(PDS) SYSADM.DTL.SRCLIB. I would like the compiled output-panel to be stored in USER.ISPPLIB. Look at how I have filled in the details on the above screen. After filling in these details, hit ENTER Key to run the Compiler-Software. Once, the compilation is done, you can go ahead and test your panel, to see for yourself, how it looks. Go to ISPF Primary Menu Option 7.2. Here, you must enter your panel’s name.

Q. How do you create Action-Bars and Pull-Downs?

The Action-Bar is like the Menu-Bar on the Microsoft Office Word-Processor. Once you click or select a Menu, a pull-down with several options appears. It is one of the most important elements of a User-Interface. Although DTL allows you to create an Action-bar Menu, it is the responsibility of the Programmer, to map these Menu-Items to the correct functions. This is not a part of the presentation-layer. To create a new Action-bar you would code the <ab> and </ab> tags. In the Action-Bar, to create an Action-Bar Choice you write <abc> and </abc> tags. Under each action-Bar, you write an associate Pull-Down Choice <pdc> and </pdc>. The action to be performed when the user select a pdc, is defined using the <action run=...> tag. The value that you assign to the run attribute of the action-tag tell, which command to run(what function to perform). In addition to this, a pull-down choice may also be marked un-available, by using the unavail attribute. Check out the Panel below. I have coded four action-bar choices <abc> on the above panel, File, Edit, Options and Help. Under the File Action-bar Choice, I have coded the following Pull-Down Choices – Add Entry, Delete Entry, Update Entry and Exit. Under the Edit Action Bar choice, I have coded the Reset Pull-down Choice, under Options it is Undo and under Help, its Hi Lite. When you compile the above DTL Source-Code and test-run the generate Panel using the ISPF Primary Menu Option 7.2, the panel is DISPLAY'ed as shown below.

Q. How do I define the Panel Body?

Think of the Application-Form that you filled up for taking up an examination. The ISPF Panel-Body is like any exam-form. It may contains instructions at the top and bottom, areas that contain data fields, regions and dividers(separator-lines). The below DTL Source-Code shows, how one may write <topinst> Top Instructions and <botinst> Bottom-Instructions.   When you compile and Test-Run the above DTL Source-Code, this is how the ISPF Panel looks like -

Q. How do you code the <area> tag in the Panel Body?

The <area> tag represents the main body of the panel. In reality, you should code all the interactive fields inside an area tag. Thus, the correct way to write the <selfld> Selection-Field of the "Item Selection" Panel would be, nesting it inside the <area> tag. You can set the marginw attribute of the <area> tag, to specify a Margin-width for the area. For example, I have coded marginw=10 in the below example. Look at how it affects the panel. The entire area has a margin of 10 columns.

Q. What are Scrollable Areas?

Any area can be made scrollable, by specifying the depth, extend and div attributes. depth attribute makes the panel scrollable. You can specify EXTEND=ON on a scrollable panel, to allow it to expand beyond the logical window size. You may use the div attribute to have a divider(separator) line either before or after the scrollable area. div=blank adds a blank divider, whereas adds a visible divider. The next panel that I have coded broadly contains two areas – a simple area and a scrollable-area with depth 6.   In the first area, I have coded the Case No, Name and Address Data-Fields. I have also coded a Selection-Field for the Case – Is it civil case, or real-estate or Environmental. In the Scrollable-Area, I have coded a Multiple Selection-Field for the Type of offense, with several choices.   See below, how this panel actually looks like, when it is displayed. When you scroll down by pressing PF08 Attention Key, the remaining part of the scrollable panel is displayed.

Creating a new IMS Database

Q. How do COBOL Programs access Data using IMS/DB Software?

COBOL-Programs use READ and WRITE Instructions to access Data from Files. This invokes or calls a helper-program called Access-Method. The Access-Method Software actually knows the details of how the data is organized, and the location(place) – where the record is stored physically on the big DASD-Disk. The Access-Method actually gets the Data from the File, in units of raw Blocks like 0001HARRYPOTTER1000MUMBAIINDIA. But, the access-method has no knowledge about the Record's format or structure – what are the fields in the Record. The Data fetched would be useless, or of little value if you don’t know its structure or Format. In an H2O water-Molecule, it is the Atomic-Structure that is important. On the same lines, Data is meaningful and can be processed, if you know its structure like (EMPID,FNAME,LNAME,SALARY,CITY,COUNTRY).  In simple COBOL-File IO Programs, this format, structure or File-Layout, that I am stressing on, is hard-coded or embedded in the COBOL-Program. The COBOL-Program sees the same record-format, as that of the actual-record in the File on the Disk. By contrast, when data is stored and managed by the IMS/DB Software(one more layer added to the Onion on the right), the COBOL-Program is now unaware of the Structure or record-format. The COBOL-Program talks with the IMS/DB Software which stores structure-details. The complicated details of the record-format and Structure are now taken care of by IMS/DB Software, and the COBOL-Program is spared and relieved from this botheration. The IMS DB/Software in turn, calls the Access-Method Software to actually GET the Data from the Disk-Dataset. The IMS/DB-Software Interface in return presents this Data to the COBOL-Program in the form of Segments. The IMS/DB Software does provides an Abstraction.

Q. How do you create a fresh New Database-File to store Data? Do I go to ISPF Menu Option 3.2?

Say that, you wanna store the data about your Shopping-List – the list of items that you want to buy from the Super-Market, in a Mainframe-File, and you want IMS/DB Software to help you manage your Shopping List. This means, if you want to add an item to the Shopping-List, remove an item from the Shopping-List, or take a Print of all the Items in the Shopping-List, you are gonna ask IMS/DB Software to do it for you. The sad part is, IMS/DB Software can't read Sequential-Files. IMS/DB Software has the ability to read and write data to VSAM-ESDS Files. Hence, if you plan to use IMS/DB Software to manage your data, better create blank(empty) VSAM-ESDS Files to hold your valuable-Data. I have created an Empty New VSAM ESDS File IMS810.INVENDB by running the free IBM-Software Tool IDCAMS. I'd use this Empty VSAM Database-File created newly, load my data into it, and then ask IMS/DB Software to manage this data in the future.

Q. What are Control-Blocks?

Whenever a COBOL Program, sends requests to the IMS-DB Software, to access data from the VSAM Database-File, IMS-DB Software cannot directly service it. To support the request, the IMS-DB Software needs (i) The Blue-print of the Database and (ii)the database privileges, the program has. These details are stored in specialized Load-Modules called Control-Blocks. IMS-DB Software uses the Control-Blocks as a ready-reckoner, and constantly refers to them, for any requests that come along.

Q. What is DBD Control-Block?

The DataBase Descriptor or DBD Control-Block, contains the Database-Structure details – what are the different segments in this data, what are the fields in this segment etc. The DBD Control-Block contains the design of the database, it's a blue-print. Every Database must have a DBD Control-Block. Say if, there are two hierarchical databases X and Y, there’s got to be two DBDs.

Q. What is PSB Control-Block?

The Program Specification Block or PSB Control-Block contains details about, the Database Privileges granted to a COBOL-Program. The PSB will specify, what database-segments the program is allowed to access, the type of access(Get, Insert, Update, Delete). The IMS-DB Software uses the PSB Control-Block, to prevent unauthorized access and enforce security. If the Program attempts to access a segment in the database, which is not allowed in the PSB Control-Block, it is a security violation and the IMS-DB Software restricts it. Every Program must have a PSB Control-Block. Say, if there are two Programs, there's got to be two PSBs. Moreover, a Program's PSB internally  contains a PCB(Program Control Block). For each database accessed by the Program, there is one PCB in the PSB Control-Block. In the above picture, the first–program can access both Database-X and Database-Y, but the the second-program is only allowed to access the Database-X.

Q. Who creates the Control-Blocks?

How do you write or code a new Control-Block? You first write the Source-Code of the Control-Block in Assembler Language. But, the Mainframe-Computer doesn't understand Assembler. It knows only Binary Machine Language 0's and 1's. So, after writing the Source-Code, you Assemble-Link it to produce a Binary Load-Module for the Control-Block. IMS/DB Software shall always refer to these Control-Block Load Modules(containing Database structure-details), while storing or retrieving Data from the Database-File. You go about creating two control-blocks - (i) DBD Control Block and (ii) PSB Control-Block.

Q. How do you write the Source-Code of the DBD Control-Block?

The secret to writing Source-code for DBD-Control Block, is you’ve got to think, "What's the Structure of the Data, that you are going to store in the VSAM-ESDS Database-File?" Say for example, I want to generate DBD Control-Block for the Inventory-Database. A pictorial representation of the Inventory-Database Structure is given below.   Here's a brief description of the Inventory-Database. The Inventory-Database has three segments – Vendor, Item and Stock-Location. When you begin to write Assembly Language Source-Code for the DBD Control-Block, ask yourself, "What are the segments in this Database"? For each segment, you code a SEGM Macro. This is how the skeleton of the Source-Code looks like. Code 3 SEGM Macros, one for VENDRSEG, one for ITEMSSEG and the last for STLOCSEG. The PARENT Attribute on the SEGM Macro tells, "who's the Parent of this Segment"? Since, Vendor Segment is the root, I coded PARENT=0 on it. On ITEMSSEG, I coded PARENT=VENDRSEG and likewise on STLOCSEG, I coded PARENT=ITEMSSEG. For each Segment, the BYTES Attribute indicates the total Sum-Length of all the Fields in that Segment. I’ll revisit this attribute a little later.   Now, every Segment VENDRSEG, ITEMSSEG and STLOCSEG can have many fields. Code the FIELD Macro once, for each Field. FIELD Macros go under the appropriate SEGM Macros. I am gonna explode each segment one-by-one, and show you how to code its Fields.  Vendor Segment is the list of the Vendors, which supply Raw-Materials. Every Vendor has a 3-Character Alphanumeric Code-Number, a name, an address, city, state and Zip-Code where the Vendor is located and Telephone-Number and Contact-No. The BYTES Attribute indicates the length of the Field. The START Attribute indicates the Starting-Position or Offset(Displacement) of the Field. Let me elaborate it : VENDRNAM is 30 Bytes in Length, and starts from Position 34. It implies VENDRNAM spans from Position 34 to Position 63(30 Bytes). Consequently, the next successive Field VENDRADR will start from Position 64 and so on. An easy formula to remember this is – Starting Position = (Previous Field's Start + Previous Field's Length). Moreover, the TYPE Attribute indicate the type of data. Alphanumeric or PIC X Fields have TYPE=C. Numeric Fields(PIC 99) have TYPE=Z. Packed Decimal( PIC S9(05)V99 COMP-3) have TYPE=P. If you sum-up the field-lengths of VENDRCOD, VENDRNAM, VENDRADR, VENDRCIT , VENDRSTA, VENDRZIP, VENDRTEL and VENDRCON = (3+30+30+17+02+09+10+30) = 131 Bytes. It means the One Vendor's data will be 131 Bytes in size. So, you code BYTES=131 on the Vendor Segment's SEGM Macro.    When you write a COBOL-Program to fetch the Vendor-Data from the IMS-Database, the Vendor-Data received from the IMS/DB Software into the COBOL-Program needs to be stored or kept somewhere. You need COBOL-Variables corresponding to each of these VENDRSEG Fields that will store or hold the data in the COBOL-Program, when it received from the IMS Vendor Segment. Here, is the COBOL Copy-Book(a separate Mainframe File) containing the COBOL Variables corresponding these VENDRSEG FIELDs. One Vendor may supply several Items. Item Segment represents the list of the Items, which a Vendor supplies. Every Item has an Item-Name, a short description, unit-price or cost of the Item and the average cost of the Items. Here’s the DBD Source-code for the ITEMSSEG Segment. The COBOL Copy-Book Layout(a Separate Mainframe File) corresponding to the Above ITEMSSEG, is shown below.  One Item may be stocked or stored at multiple-locations or warehouses. Stock-Location segment represents the list of the locations, where an item is stored or stocked. Each Location is identified by a 3-character alphanumeric code. At every location, important-details about the inventory such as what is the quantity-on-hand, what is reorder-point, what is the quantity-on-order, and the last re-order date is recorded. This picture shows, how I wrote the DBD Source-Code for the Stock-Location Segment. The COBOL Copy-Book Layout(A Separate Mainframe File) corresponding to the above Stock-Location Fields, is in the snap below.

Q. How do I assemble and Link the above DBD Macros?

I have the following setup at my shop. I have created a Library(PDS) for storing the DBD Macro Source-Codes called IMS810.DBDSRC. I have keyed in my DBD Source-code in a Member INVDBD, under the Source Library. I have another Library(PDS), which will contain the corresponding DBD Control-Blocks Load Modules, which are produced after assembling the source-code. My DBD Load-Library is IMS810.DBDLIB. Before you run the assemble-link job, you should have your own personal DBD-Source and Load-Libraries setup. To Assemble and Link your DBD-Code, you run the Assembler-Software (EXEC PGM=ASMA90) first and followed by the Linker-Software(EXEC PGM=IEWL). So, you write a simple two-step Assemble-Link job. You can download this JCL by clicking here. This is how it looks. There are four-variables that you need to set. The DBDNAME Parameter is the name of the DBD. The SRCLIB Variable is the DBD Source-Library. The MACLIB Variable is the IMS Macro-Library. You should ask the System Programmers at your shop and find out, the name of the IMS Macro Library. Last, the DBDLIB is the name of the DBD Load-Library.

Q. How do you write the PSB Macro Source Code?

A PSB Control-Block is like a Entry Pass(Ticket). The PSB helps prevent any unauthorized Access to the Data. IMS/DB Software checks PSB Control-Block to enforce Access-Control. Every COBOL Program that accesses IMS/DB Database, has its own PSB(Entry Pass). In fact, it is customary to have the PSB-Name same as the Program-Name. Inside each PSB, there are several PCBs. Suppose there are two Databases –Employee Database EMPDBD and Inventory Database INVDBD, that the program needs access to. You code a PCB-Macro for each Database, that the program accesses. The PCB Macro, essentially tells the Processing Options PROCOPT=G. PROCOPT Parameter is damn important and indicates the Access-Privilege. For example, to authorize the program to only read the data from the Database, code PROCOPT=G. On the other hand, for a Program to initially load data into the the Database, coding a PROCOPT=LS is necessary, and so on.. Look, how I have written the Source-Code for the a simple PSB which has one-PCB for the Inventory-Database. If a Program uses this PSB, the program will only be able to access Inventory Database(and not Customer Database). You may also download this Source-Code by clicking here. Following the PCB-Macro, you may code the SENSEG or Segment Sensitivity Macros. You code one SENSEG Macro for each Segment. The NAME Parameter indicates the name of the Segment. I have coded three SENSEG Macros for VENDRSEG, ITEMSSEG and STLOCSEG.

Q. How do I assemble and link the above PSB Macros?

I have the following setup at my end. I have created a Library(PDS) for storing my PSB Macro Source-Codes IMS810.PSBSRC. I have keyed in my PSB Source-Code in a Member INVPSB under the Source-Library. I have another Load Library or PDS IMS810.PSBLIB, which will contain the PSB Control-Blocks Load-Modules, produced on assembling the Source-Code. My advise to you is, go ahead and first setup your Own personal PSB Source-Library and Load-Library before you run the Assemble-Link Job. Just like the DBDGEN Job, I have written a PSBGEN Job to Assemble-and-Link the PSB Code. See below how the PSBGEN Job looks. You may also download this JCL Code by clicking here. There are four variables, that you need to set. PSBNAME is the name of the PSB. SRCLIB is the Source-Library containing the PSB Macros Source-Code. MACLIB is the IMS Macro Library. PSBLIB is the Load-Library where the PSB Control-Blocks reside.

Comparing COBOL and Assembler Programs

Q. What are the different types of Assembler Statements?

There are three types of Assembler Statements – (i) Instructions : These are actual Machine Instructions,  which when executed by the Mainframe, perform some operation on the Data for example MVC(Move characters) and AP(Add Packed). (ii) Assembler Directives : These are directions, commands or orders meant for the Assembler Software(ASMA90) rather than the Mainframe Computer, for example SPACE(to space out lines on the listing – like SKIP in COBOL) and END(to mark the end of the Assembler Program). (iii) Macros : These are instructions which are further expanded(substituted) by the Assembler to produce more Instructions, for example OPEN(for opening a file), GET(for reading a record), PUT(for writing a record). In COBOL, words are grouped together to form a Clause. COBOL-Clause is just like an Assembler-Statement. Several clauses form a Sentence. Many sentences go on to make up a Paragraph, many para's give a SECTION, and many sections form a DIVISION.

Q. What's the syntax of the Assembler Language like?

An Assembler Instruction is made up of 5 different Parts. 1. An Optional-Name or Label – You can assign a name to every Assembler Instruction. This corresponds to a COBOL File-Name, data-name or Paragraph-Name in the DATA and PROCEDURE DIVISION. For example, in the below snap PRINTER is the Internal File-Name. 2. A required Operation-Code – The Operation-Code or OPCODE, represents the Assembler Statement that you want to execute – it may be Machine Instruction, Assembler Directive or a Macro. Generally, the convention followed is to start coding the Opcode from Column 10. In the above snap, DCB is the operation-code. 3. Optional Operands – Any Assembler Instruction can carry one or more Operands. Each Operand follows the format Parameter=Value. The list of parameters are separated by commas. DDNAME=OUTFILE,DEVD=DA,MACRF=(PM), are all operands. You normally start coding the first operand from Column-16. 4. Optional Comments – You can write anything you want describing the code as Comments. Comments can begin anywhere after the Operands, but there must be at-least one blank space between the Last Operand and the beginning of the Comment Line. 5. An Optional Continuation-Indicator – When you want to continue an Assembler Instruction over to the next-line, you code a continuation character in Position 72 of the Assembler Statement. The continuation character could be anything other than a blank(white-space). The continued lines should begin normally in Position 16.

Q. Is there any restriction on the length of File-names, data-names or paragraph names in Assembler?

It is most likely that you are using High-Level Assembler Assembler H at your shop. Assembler H allows labels upto 63 characters. In certain cases only names of length 8 are allowed, for example program-name or sub-routine names. Many old Assembler programmer continue to use the older limit of 8 characters out of habit. I personally feel, its wise to stick to the 8-Character Limit.

Q. What are the important positions in an Assembler Statement?

Position 01 is called the Begin-Column, Position 71 is called the End-Column. You code Assembler statements between the Begin-Column and End-Column. If the instruction is longer, you should put a continuation character in column-72 known as continuation-indicator field. Position 16 is called the Continue-Column.

Q. Do I need to watch out for anything?

Absolutely, there's no room for errors. A goof-up could be costly, and sometimes unlike JCL or COBOL, the errors would not even show up. I would like to warn you, that when a Assembler statement is continues onto the next Line, one needs to put a comma at the end of the first Line. In the snap below, forgetting to put a comma after MACRF=(PM), makes Assembler think RECFM, LRECL, BLKSIZE and DSORG are comments. As seen, they’ve been highlighted in Turquoise.   Another typo that you are likely to commit, when start coding Assembler is putting extra-commas.

Q. How do you form a valid Label in Assembler?

A Label in Assembler is textual character-string, made of A-Z, 0-9, @, $ and #. Assembler H also supports the underscore sign '_'. Generally, in COBOL Programs, you find paragraph names such as 300-HOUSEKEEPING, 2500-PRIMING-READ, 2450-CHECK-RC etc. Paragraph-names start with digits, because it aids the COBOL Programmer to know the direction in which to find the paragraph, when he looks at the COBOL Program Listing. In Assembler, labels cannot start with a Digit. The underlying reason for this is because, Assembler-Programmers don't need to have something in the Label, to tell them the place where the Label is Located. The Assembler Listing automatically tells them where the Label is. More on this later. The assembler software puts the address each label referred to in a Branch Instruction, in the ADDR1 Column. By looking at this value, and comparing it with the current LOC Value, you can determine whether the Label precedes or succeeds the current Line. You have to get into the habit of looking the Address in ADDR1 and ADDR2 Columns of the Assembler Listing to locate Labels, and be a productive Assembler Programmer.

Q. A COBOL Program has a definite Layout IDENTIFICATION, ENVIRONMENT, DATA and PROCEDURE DIVISION. What about Assembler?

Assembler does not follow a strict, rigid layout for writing Programs. It is far more relaxed than COBOL's organization of Programs. Below, I have enlisted what each DIVISION of a COBOL Program does.   What I do is, I write Assembler Programs in a sequence, which roughly approximates the above structure. Program-name Program-description(comments) Actual Instructions File I-O Areas, working-storage areas File-names and Dataset Control Blocks(DCB) External–record and data descriptions(in dummy sections-DSECTS)

Q. How do you decode the Assembler Listing?

I am gonna elaborate the Assembler-Listing that was produced for the Program ASPROG02. The complete assembler-listing can be found, by clicking here. The first-page of your Assembler Listing should be titled External-Symbol Dictionary, commonly abbreviated as "ESD". 1. The SYMBOL Column shows any Control-Section(CSECT) names and ENTRY Names inside your Program. 2. The ADDR Column shows where the name under the SYMBOL Column is located. In this case ASPROG02 begins at Address 0 within the Program. 3. The LENGTH Column tells the Length of the name in the SYMBOL. In this case, the size of Program ASPROG02 is hexadecimal X'3CC'(972 Bytes). The next Page and several subsequent, contain the listings of instructions in your Program. This is the same information provided in a COBOL PMAP or CLIST. LOC – This contains the location, or hexadecimal Displacement of the Statement from the beginning of the Program. Object Code – This contains 3 columns. Not all the 3 columns are always filled. This is the Actual Machine Instruction generated by the Assembler, which you would find in memory in the Dump. ADDR1 – This column will contain the Hexadecimal address of the first operand in the instruction that you have coded. This is what is printed in the LOC Column of where the Label is actually coded. ADDR2 – This column will contain the Hexadecimal address of the second operand in the Instruction. STMT – This column will contain the Line-Number or Statement-Number. SOURCE STATEMENT – This is the actual 80-Byte Assembler Source Statement. Understanding the Assembler Listing is very important to be a good Assembler-Programmer. 1. Take a look at Statement 15. LA 2,SAVEAREA For the second-operand SAVEAREA, the assembler has substituted the hexadecimal address ADDR2=X'DC'. Now find the, hexadecimal Address X'DC' in the LOC Column. That's, where SAVEAREA is defined. 2. Locate the Statement AP RECNUM,ONE Both ADDR1 and ADDR2 Columns should have a printed value there. RECNUM is substituted by ADDR1=X'304' and ONE is substituted by ADDR2=X'309'. Scan the Program until you find these addresses. You should try practicing this a few more times, till you've mastered it. Following the Assembler Instruction Listing, there will be the Relocation-Dictionary or "RLD". The RLD will be used by the Loader when it brings your program into Memory for Execution. For the moment, I’ll skip the RLD. Next, you shall find the Cross-Reference Listing. SYMBOL – The name of the field, or Instruction-Label, just like the name in a COBOL Cross-Reference XREF Listing. LEN – The Assembler’s computed Length for that symbol. How much storage space does it occupy in Bytes? VALUE – This contains the Hexadecimal address of the location of the Symbol. DEFN – The Statement number where the Symbol was defined. If you accidentally define a Symbol twice, the Assembler will list it in the Cross-reference and flag the second definition as duplicates. References – The statement where the symbol was referred. When the Assembler-Program contains errors, the Assembler provides diagnostic information about the error at two-places. First a line containing, * * * ERROR * * * is printed following the statement with the error. Secondly, after the Cross-Reference, a summary of all un-acceptable erroneous statements that were flagged is printed as Statistics.

Introduction to IMS/DB

Q. What is IMS/DB?

IMS(Information Management System) is the Hierarchical-Data Management System from IBM. When hierarchical data-structures are implemented using Flat-Files, it is the responsibility of Application-Programmers to ensure that it works flawlessly. Why storing huge-volumes of data having hierarchical-relationship in Flat-Files is a bad idea? Let's say, a list of Employees and the Departments in which they work – this Data is stored in Flat Files. The Departments Data is stored in DEPARTMENT File. The record-layout of the DEPARTMENT File is shown in the picture above. Every Department has a DEPARTMENT-ID, that uniquely identifies the Department. Moreover, a Department has a DEPARMENT-NAME and the total number of employees working under that department are recorded in DEPARTMENT-STRENGTH. Every Department of the company has several Employees working under it. The Employees data is stored in EMPLOYEE File. The snap above shows its record-layout. Each Employee is identified by Unique EMP-KEY, consisting of EMP-ID and DEPT-ID. The Employee's name EMP-NAME is further broken down in FNAME, MNAME and LNAME. The Employee’s Joining Date is stored in EMP-JDATE. This hierarchical relationship between DEPARTMENT File and EMPLOYEE File is depicted in the picture below.    However, there are certain problems with this design. 1. Maintaining Data Consistency - For instance, if the Program adds a new Employee-Record, that has no DEPT-ID, no corresponding department, the DEPARTMENT and EMPLOYEE Files will no longer be synchronized. And the same is true, if a Department-Record is deleted, when active Employees work for that Department. These Employee-Records are orphaned out. 2. COBOL Program and Data Dependency – Because the structure of the Data(File Layout) is hard-coded or embedded in the COBOL Program accessing the data, whenever the data's structure changes(say you add one more field to the DEPARTMENT File), the COBOL Program has to be re-written and re-compiled all over again. The Program heavily depends on the Data. When you use IMS/DB for storing data, difficulties like these don't come up. That's because the hierarchical relationships between data is now taken care of by IMS. IMS would use a single file for storing DEPARTMENT and its EMPLOYEE's data. The structural information is stored in IMS.

Q. What is meant by Segment-Type, Segment-Occurrence and Levels in IMS?

In IMS/DB, when data is stored about any real-world thing, you call it a Segment. For example, if you record information about Employees, Employee is one-Segment. Because you would be storing  Departments is another segment. In IMS Jargon, I would call them DEPARTMENT Segment and EMPLOYEE Segment. I'll introduce two new terms as well – Segment Type and Segment Occurrence. A segment-type is one category or class of data. For example, DEPARTMENT Segment-Type. Each instance of a Department is called a Segment-Occurrence. For example, you may have 3 segment-occurrences HR, MARKETING and FINANCE of the Segment-Type DEPARTMENT. Bear in mind, there can be only one segment-type of a particular kind, but infinite occurrences of it. An IMS Hierarchical-Database can be looked upon as an inverted-tree. The Height of the Tree tells you the number-of-levels in the Tree.   This Hierarchical-database has two Levels.

Q. What is meant by Root-Segment and Database Record?

In an IMS Hierarchical-Database, the segment-type at the top of the hierarchy-tree is called the Root-Segment. For example, in the below database, the DEPARTMENT-Segment is called the Root-Segment.       Suppose the DEPARTMENT Segment-type has 3 segment-occurrences HR, Marketing and Finance. Each of these Department segment-occurrences have Employee Segment-occurrences subordinate to them. HR Department has 2 sub-ordinate Employee Segment-Occurrences RAM and RAJ. Marketing Department has 3 sub-ordinate Employee-Segment occurrences RAKESH, RAVI and RAJESH. Finance Department has 2 sub-ordinate Employee Segment-occurrences ROMEO and ROY.   One root segment-occurrence e.g. HR plus all the segment-occurrences sub-ordinate to it for example RAM and RAJ, together constitute one Database-Record. Thus, here there are 3 database-records, one for each root segment-occurrence. In all, there are 10 segment-occurrences in this IMS Database.

Q. What are dependent, parent and Child and twin Segments?

All the segments in an IMS Hierarchical DB, other than the Root-Segment are called Dependent-Segments. DEPARTMENT Segment is called Parent-Segment and EMPLOYEE Segment is its Child-Segment. The term Twin segments is applicable to Segment-Occurrences. Two children with same parent segment-occurrence are called twins. For example, RAKESH and RAVI are child of the same parent segment occurrence Marketing Department, so they are called Twin-Segments.

Q. How data is accessed in an IMS Hierarchical Database?

Data can be accessed in two-ways from an IMS-Database – Sequential and Random mode of access. When you access data from IMS DB Sequentially, you read it record-by-record. Within each record, the segments are accessed in the following general pattern : Top-to-Bottom, Left-to-Right. First, a root segment-occurrence is retrieved. Then, IMS DB digs as far deep as possible, right at the bottom, until it reaches the lowest level Segment-Occurrence. It then retrieves all the twin segment-occurrences at that level. Once, all the Twin Segments have been fetched, IMS moves back up in the hierarchy and retrieves any twins of the Parent. This process continues, till all the Database Records have been retrieved. So, the sequence in which the Data is fetched is HR-RAM-RAJ, MARKETING-RAKESH-RAVI-RAJESH and FINANCE-ROMEO-ROY.   Random-Access to Data in a Hierarchical-Database is possible by supplying a concatenated-Key. Every Segment can have a Key-Field(or Sequence Field). For example, DEPARTMENT-ID may be a Key-Field of DEPARTMENT Segment. EMPLOYEE-ID would be Key-Field of Employee-Segment. A Concatenated-Key is formed by combining the Key-Fields of different segment-types  e.g.(DEPARTMENT-ID,EMPLOYEE-ID). This way you can jump or skip  directly to any particular Segment-Occurrence under any Database Record.