KR-229*; DIFs, DOFs, MIDs and MODs!

 

IMS is something we haven’t dealt with in KRs – so here’s one on IMS.

 

There are times in online programming when you might get the error MID and DIF are incompatible; what is MID and DIF?

 

MFS (Message formatting service): It is part of IMS TM (transaction manager) - which is basically the online portion of IMS (IMS DC). The database part is IMS DB.

 

What does MFS do?

• It enables the application programmer to forget worrying over what device terminals are being used to communicate with the application. For instance you might code a banking online application that needs to be accessed by different terminals – the usual 3270 or some other terminal like 2740, 241 etc.
• Each terminal will have specific features and way in which data should be sent to the terminal; if programmers had to worry about these details then the code would need to handle each of them which is a cumbersome task.
• Here enters MFS. Concept is similar to why we have databases - applications needn't bother about how data is stored physically. Similarly using MFS applications needn't bother about the physical device they are interacting with.
• MFS resides between the physical terminal and application program. When a screen is generated in IMS, four control blocks are created: MID, DIF, MOD and DOF (the four blocks can be said to be part of MFS).
  DIF -> Device input format; depends on the device from where the input is taken.
  MID -> Message Input Descriptor; defines the format of the input for the application program.
  We have a MOD and DOF for output.
  MOD-> output info and layout sent by application program.
  DOF-> device output format – defines what data is sent to the device.

Flow will be:

Terminal -> DIF -> MID -> Application program

Then application program processes info and sends output in this chain: Application program -> MOD -> DOF

• DIF/DOF are usually the same (the screen layout is going to be the same both ways).
• MID/MOD will actually just be the I/O PCB -> it will have the variable names (i.e. any field other than screen labels) in sequence with the only differences being: MID will have a transaction name field while MOD will have LL (length of output message) and ZZ (MFS control info).
• MFS will use the data in MOD to populate what is required in the DOF; and the DOF will appear on the terminal device.
• Similar process happens for DIF and MID as well.
• You would have a FORMAT (or TFORMAT) pds in your system where these control blocks are stored – check out the process you follow when you make screen changes to an IMS DC program and you will be able to map this theory with reality.

---

 

KR-233*: IMS lands man on moon

 

We’ll have a few KRs on a topic we haven’t really touched upon much…

IMS (Information Management System); it was created in 1968 to enable realizing the dream of man walking on the moon; You must be saying - “IMS and NASA? No way – how did IMS help man get to the moon” – actually developing the spacecraft involved procuring material from a large number of vendors – managing all of that led to the creation of IMS; IMS generates around $1 billion revenue annually for IBM even today.

So now you have some arguments to counter people who say IMS is outdated!

 

You will generally encounter three types of IMS programs:

 

1.) DLI – pure batch program.

Typically these programs run when the online regions are down and the program will have exclusive access on the databases it accesses. You write a JCL to execute them – just like any normal COBOL program is executed.

 

2.) BMP (Batch message processing)

These are also like batch programs but they can coexist while the online region is running; no need to bring down anything for these to run. These programs will also be executed through a JCL but the parameters used will vary.

 

3.) MPP (Message processing program)

The normal online IMS DC programs which will have front end screens where the user can interact with the system.

 

More clues:

 

The PSB (program specification block) defines the PCB (program control block) for each DB or terminal accessed by the program.

So in the PSB a PCB TYPE=DB entry means it could be used by a MPP, BMP or DLI program while a PCB TYPE=TP means it could be used by a MPP or BMP program only.

 

 

---

KR-234*: PSB, PCB, DBD, ACB

 

DBD (database descriptor)

• In DB2 the DBD is actually an internal representation of the DB2 catalogs.
• In IMS the DBD defines the structure of the database; each database will have a DBD.
• All segments and fields which we want to search by, need to be specified in the DBD.
• Since each segment is defined the application program will retrieve a segment and work with that data – but do we need to change the DBD each time we add a new field to the segment? Yes if you want to use that field in the IMS queries.
• Usually we would leave some free space in each segment which we will later use when introducing new fields – and if those fields don’t need to be used in queries and if those fields can be fitted within the existing free space then no DBD change is required.

PSB (program specification block)

• Specifies what all databases and what all fields in each database an application can access. For each database that the program wants to access you will find a PCB (program control/communication block) defined in the PSB.
• The PCB will say which database to access, which segments can be accessed etc. These are called DB PCBs.
• A PSB can contain multiple PCBs.
• If the program needs to access a terminal (or get user input from a terminal) then those terminals are also defined in PCBs (these are called IO PCBs). An alternate PCB is used when we want to pass a message to another transaction program.

 

ACB (application control block)

• At runtime IMS will use the PSB and DBD to actually access the physical database; to make this process faster it creates an ACB.
• For online IMS DC programs (MPPs), the programmer should create ACBs beforehand (kind of like static ACBs) while for batch programs IMS will create the ACB at run time (dynamic).
  

PSB and application name should be the same for an MPP.

 

Have you seen PSBs where there are no IO PCBs (no terminals) mentioned but the code has an IO PCB? More on that in the next edition…

 

---

 

KR-235*: Patting CMPAT

• An I/O PCB is passed by IMS to an online application program when it is run in the online ims region.
• I/O PCBs are required only when the program is running in an online region (because in the online region the program is expected to communicate with the outside world). We do not explicitly code an I/O pcb in the psb. IMS gives it to us on its own.
• But if we run the same program in batch region (for testing purpose), IMS will not pass the program any I/O PCB because it is running in batch.
• Thus to test such a program (an MPP/BMP) in batch we would need to remove the I/O PCB from the code and recompile (because in the code we specify the list of PCBs the program expects from IMS – so when running in batch we have to make this change).

CMPAT option

• IMS provides a simpler mechanism for this – in the PSB used by the program just specify CMPAT = YES; now even when the program runs in a batch region IMS will pass an I/O PCB to the program. So the program is coded with an I/O pcb and irrespective of online/batch region it will have a I/O pcb – no code change needed.
• Ok; enough of all this you say – where do I see this being used? If you are using a Batch Terminal Simulator (BTS) which enables simulation of transaction processing (TP) in batch mode then you would need such program’s PSB to have a CMPAT = YES. (BTS helps in debugging IMS programs by displaying detailed information about the IMS calls made – can be used for both batch and online programs but online programs will also need to be run in batch mode for BTS).

Reading all of this you begin to wonder how PCBs are used by IMS and by our programs – more on that in the next edition (guess we are going from complex to simpler topics; reverse KRs!)