SINDIA7 Programmer's Guide - Atossupport.bull.com/ols/product/system/gcos7/gcos7-com/g7-dps7000/doc-com/... · 47 A3 56BB Rev02 iii Introduction The purpose of this manual is to provide

SINDIA7

Programmer's Guide

DPS

7000/XTA

NO

VASC

ALE

7000

Transaction Processing: SINDIA7

REFERENCE47 A3 56BB 02

DPS7000/XTANOVASCALE 7000

SINDIA7Programmer's Guide

Transaction Processing: SINDIA7

March 1995

BULL CEDOC

357 AVENUE PATTON

B.P.20845

49008 ANGERS CEDEX 01

FRANCE

REFERENCE47 A3 56BB 02

The following copyright notice protects this book under Copyright laws which prohibit such actions as, but notlimited to, copying, distributing, modifying, and making derivative works.

Copyright Bull SAS 1989, 1995

Printed in France

Suggestions and criticisms concerning the form, content, and presentation of thisbook are invited. A form is provided at the end of this book for this purpose.

To order additional copies of this book or other Bull Technical Publications, youare invited to use the Ordering Form also provided at the end of this book.

Trademarks and Acknowledgements

We acknowledge the right of proprietors of trademarks mentioned in this book.

Intel® and Itanium® are registered trademarks of Intel Corporation.

Windows® and Microsoft® software are registered trademarks of Microsoft Corporation.

UNIX® is a registered trademark in the United States of America and other countries licensed exclusively throughthe Open Group.

Linux® is a registered trademark of Linus Torvalds.

The information in this document is subject to change without notice. Bull will not be liable for errors containedherein, or for incidental or consequential damages in connection with the use of this material.

47 A3 56BB Rev02 iii

Introduction

The purpose of this manual is to provide the information necessary for analyzing,developing and optimizing transactional applications under GCOS7. It is thereforeintended for use by the programmer analyst. It also provides the system supervisor withthe information necessary for installing, tailoring and using SINDIA7 under GCOS7.

The aim of this manual is not replace the manuals specific to SINDIA7, TDS or GCOS7for an extensive use of these products. It attempts to show how to implement atransactional application under GCOS7 using SINDIA7 easily, efficiently and resulting inthe best performance. Greater emphasis is placed on providing the sequences of basicactions to be undertaken to perform a function than in thoroughly describing each of thepossible parameters.

Three functionalities, Project and User Profile Management, Data Dictionary and BATCHprogram skeleton generator, are also described.

In keeping with our concern for simplicity, the SINDIA7 on- line documentation will proveto be a useful reference guide when working in context.

You should read this manual before actually using SINDIA7. Prior knowledge of TDS ishowever not necessary to understand this document, but it would be helpful to read themanual entitled "TDS Concepts".

Transactional Applications under GCOS 7TDS - SINDIA7 Overview

iv 47 A3 56BB Rev02

47 A3 56BB Rev02 v

Table of Contents

1. Developing Transactional Applications under GCOS7 ...................... 1-1

1.1 TRANSACTIONAL APPLICATION: GENERAL INFORMATION .............................. 1-1

1.2 STRUCTURE OF A GCOS7 TRANSACTIONAL APPLICATION .............................. 1-2

1.3 TDS/GCOS7 FUNCTIONS ......................................................................................... 1-3

1.4 USING A TRANSACTIONAL APPLICATION GENERATOR .................................... 1-4

1.5 GENERAL DESCRIPTION OF SINDIA7 .................................................................... 1-6

2. The SINDIA7 Method .......................................................................................... 2-1

2.1 INTRODUCTION......................................................................................................... 2-1

2.2 ANALYZING A TRANSACTIONAL APPLICATION ................................................... 2-2

2.3 OUTLINE OF THE SINDIA7 ANALYSIS SHEET ....................................................... 2-3

2.3.1 Exchange Identifier Column ..................................................................................... 2-32.3.2 Level Column ............................................................................................................. 2-42.3.3 Operator action description (line marked "0" in "2") ............................................. 2-42.3.4 Processing description (line marked "T" in "6") .................................................... 2-42.3.5 Name of COPY clauses linked to processing ("10") .............................................. 2-5

2.4 USING THE SINDIA7 ANALYSIS SHEET .................................................................. 2-5

2.5 CHAINING BETWEEN EXCHANGES ........................................................................ 2-7

Transactional Applications under GCOS7

TDS - SINDIA7 Overview

vi 47 A3 56BB Rev02

2.6 STANDARDIZING FORMS ......................................................................................... 2-7

2.7 SINDIA7 COMMANDS AND USER COMMANDS ..................................................... 2-8

2.7.1 SINDIA7 Commands .................................................................................................. 2-82.7.1.1 END Command (F) ..................................................................................................... 2-92.7.1.2 CAN Command (ABT)................................................................................................. 2-92.7.1.3 HLP Command (SVP) ................................................................................................. 2-92.7.1.4 RPT Command (BIS) .................................................................................................. 2-10

2.7.2 User Commands ........................................................................................................ 2-102.7.3 Function keys linked to a command ....................................................................... 2-112.7.4 User Command: An Example ................................................................................... 2-11

2.8 PROGRAMMING COMMAND TRANSACTION EXCHANGES ................................. 2-14

2.9 RECAP: I LEVEL EXCHANGE ................................................................................... 2-15

2.10 RECAP: COMMAND PROCESSING EXCHANGE .................................................... 2-15

2.11 OPTIMIZATION: NOTION OF INDIRECT EXCHANGE ............................................. 2-16

3. Administrative Management of Project and User Profiles ................ 3-1

3.1 THE ROLE OF THIS FUNCTIONALITY ..................................................................... 3-1

3.1.1 Project Definition ...................................................................................................... 3-23.1.2 User Definition ........................................................................................................... 3-33.1.3 Object Definition ....................................................................................................... 3-43.1.4 The Relationships between User, Project and Objects ......................................... 3-53.1.5 Use of the Objects during the Development Phase ............................................... 3-6

3.2 TRANSACTION FOR ADMINISTRATIVE MANAGEMENT OF PROJECTSAND USERS ............................................................................................................... 3-8

3.2.1 Functions Offered by the GESADM Transaction ................................................... 3-83.2.2 "Project Management" Function ............................................................................. 3-83.2.2.1 Creation of a Project ................................................................................................... 3-93.2.2.2 Modification of a Project.............................................................................................. 3-113.2.2.3 Displaying a Project..................................................................................................... 3-143.2.2.4 Project List................................................................................................................... 3-153.2.2.5 List Project Users ........................................................................................................ 3-173.2.2.6 List of Project Codes Assigned ................................................................................... 3-19

3.2.3 User Management Function ..................................................................................... 3-213.2.3.1 Creating a User Profile ................................................................................................ 3-213.2.3.2 Modification of a User Profile ...................................................................................... 3-28

Table of Contents

47 A3 56BB Rev02 vii

3.2.3.3 Display of a User Profile.............................................................................................. 3-343.2.3.4 Creation of a User Profile Similar to Another .............................................................. 3-373.2.3.5 Deletion of a User Profile ............................................................................................ 3-383.2.3.6 List of Users ................................................................................................................ 3-40

4. The Data Dictionar y ............................................................................................ 4-1

4.1 PRESENTATION ........................................................................................................ 4-1

4.2 DICTIONARY FACILITIE S ......................................................................................... 4-2

4.2.1 Realization Assistanc e ............................................................................................. 4-24.2.2 User Assistanc e ........................................................................................................ 4-24.2.3 Maintenance Assistance ........................................................................................... 4-2

4.3 BASIC PRINCIPLES OF THE DICTIONAR Y ............................................................. 4-3

4.3.1 The Content of the Dictionar y .................................................................................. 4-34.3.1.1 The working and screen data...................................................................................... 4-34.3.1.2 The specific data of the SINDIA 7 objects................................................................... 4-3

4.3.2 How the dictionary works ......................................................................................... 4-34.3.2.1 The specific data of the SINDIA 7 objects................................................................... 4-34.3.2.2 The working and screen data...................................................................................... 4-44.3.2.3 Entry-structure cross references ................................................................................. 4-5

4.4 MIMIC DIAGRAM OF THE DICTIONAR Y.................................................................. 4-6

4.5 USING THE DICTIONARY ......................................................................................... 4-9

4.5.1 Creation of the Dictionar y ........................................................................................ 4-94.5.2 SINDIA 7 Transactionsmaking use of the Dictionar y ............................................ 4-94.5.2.1 GESDIC....................................................................................................................... 4-94.5.2.2 GESTRX ..................................................................................................................... 4-104.5.2.3 GESGRI ...................................................................................................................... 4-104.5.2.4 GESPRG..................................................................................................................... 4-114.5.2.5 SIMU ........................................................................................................................... 4-11

4.5.3 Mimic Diagram of the SINDIA 7 Transactions using the Dictionar y .................... 4-12

4.6 THE GESDIC TRANSACTION ................................................................................... 4-14

4.6.1 Implementation of the GESDIC Transactio n .......................................................... 4-154.6.2 Description of the Program Data (Entries ) ............................................................. 4-164.6.2.1 Creating an entry (C Command) ................................................................................. 4-174.6.2.2 Modifying an entry (M command)................................................................................ 4-184.6.2.3 Consulting an entry (I Command) ............................................................................... 4-194.6.2.4 Deleting an entry (S Command).................................................................................. 4-19



viii 47 A3 56BB Rev02

4.6.3 Description of the Working Structures ................................................................... 4-204.6.3.1 Creating a working structure (C Command) ............................................................... 4-204.6.3.2 Modifying a working structurel (M Command)............................................................. 4-234.6.3.3 Consulting a working structure (I Command).............................................................. 4-244.6.3.4 Deletion of a working structure (S Command) ............................................................ 4-24

4.6.4 Displaying the Whole of a Transaction ................................................................... 4-254.6.5 Reference of the Objects in the Dictionary ............................................................. 4-25

4.7 THE BATCH TOOLS LINKED TO THE DICTIONARY .............................................. 4-26

4.7.1 The JFSTRCOP Procedure ....................................................................................... 4-264.7.2 The JFLISREF Procedure ........................................................................................ 4-26

5. Developing a Transaction Using SINDIA7 ................................................ 5-1

5.1 OBJECTIVES .............................................................................................................. 5-1

5.2 SCRIPT FOR DEVELOPING A TRANSACTION UNDER SINDIA7 .......................... 5-2

5.3 GENERATING THE TRANSACTION SKELETON - REGENERATING THE TDS .... 5-5

5.4 ADDITIONAL INFORMATION .................................................................................... 5-8

6. TPR Encoding ....................................................................................................... 6-1

6.1 DESCRIPTION OF THE SKELETON (AFTER EXTENSION) ................................... 6-2

6.2 SINDIA7 STATEMENTS ............................................................................................. 6-4

6.2.1 Chaining ..................................................................................................................... 6-46.2.2 Receiving Data .......................................................................................................... 6-46.2.3 Sending Data ............................................................................................................. 6-56.2.3.1 Global Transmission Value ......................................................................................... 6-56.2.3.2 Individual Transmission Value .................................................................................... 6-5

6.2.4 Modifying a Video Display Attribute ........................................................................ 6-66.2.5 Recap .......................................................................................................................... 6-106.2.6 Example ...................................................................................................................... 6-126.2.6.1 Specifications .............................................................................................................. 6-126.2.6.2 SINDIA7 analysis sheet............................................................................................... 6-126.2.6.3 Programming............................................................................................................... 6-136.2.6.4 Explanations and Comments ...................................................................................... 6-13

Table of Contents

47 A3 56BB Rev02 ix

6.2.7 Message Handling ..................................................................................................... 6-146.2.8 Command Authorizatlon .......................................................................................... 6-156.2.9 Commitment Unit Handling ...................................................................................... 6-166.2.9.1 Normal case (SINLOP=" ").......................................................................................... 6-166.2.9.2 Chaining of exchanges without commitment (SINLOP = 0)........................................ 6-176.2.9.3 Chaining to an indirect exchange with intermediate commitment (SINLOP = 1 ) ....... 6-176.2.9.4 Chaining to a non-SINDIA7 TPR with intermediate commitment and

return to a SINDIA7 exchange (SINLOP = 2).............................................................. 6-186.2.9.5 Chaining to an indirect exchange without intermediate commitment (SINLOP = 3) ... 6-186.2.9.6 Chaining to a non-SINDIA7 TPR, without intermediate commitment and

return to a SINDIA7 exchange (SINLOP = 4).............................................................. 6-186.2.9.7 Note: using CAN (ABT) and END (F) commands ....................................................... 6-19

6.2.10 Receiving the current transaction name ................................................................. 6-196.2.11 Clearing the screen ................................................................................................... 6-196.2.12 Number Check ........................................................................................................... 6-19

6.3 REFERENCE .............................................................................................................. 6-20

6.4 ACCESS TO RECEIVE ONLY PRINTERS ................................................................ 6-23

6.4.1 GTWRITER - Overview .............................................................................................. 6-236.4.2 GTWRITER and SINDIA7/TDS Interfaces ................................................................ 6-236.4.3 Implementing GTWRITER in SINDIA7/TDS ............................................................. 6-24

6.5 INITIATING COMPILATION ....................................................................................... 6-25

6.6 ANALYSIS DOCUMENTATION ................................................................................. 6-25

7. BATCH program skeleton generation transaction ............................... 7-1

7.1 PRESENTATION OF THE APPLICATION ................................................................. 7-1

7.2 GENERAL PRINCIPLES ............................................................................................ 7-2

7.3 THE FUNCTIONALITIES ............................................................................................ 7-5

7.3.1 Management of the generation parameters ........................................................... 7-57.3.2 SINDIA7 Batch Source generation ........................................................................... 7-67.3.3 Editing the program documentation ....................................................................... 7-8

7.4 DEVELOPMENT OF A BATCH PROCESSING ROUTINE UNDER SINDIA7 .......... 7-12

7.4.1 The KINEMATIC files ................................................................................................. 7-127.4.2 The links between files ............................................................................................. 7-13



x 47 A3 56BB Rev02

7.5 CODING ...................................................................................................................... 7-27

7.5.1 Generation ................................................................................................................. 7-307.5.2 Input of the COBOL code of the processing sequences ...................................... 7-32

8. Optimizing the GCOS 7 Environment ......................................................... 8-1

8.1 ANALYZING A TDS SESSION ................................................................................... 8-1

8.1.1 Analyzing the JOR ..................................................................................................... 8-18.1.2 Analyzing TDS Statistics .......................................................................................... 8-12

8.2 OPTIMIZING FILES HANDLED BY UFAS ................................................................. 8-16

8.2.1 Choice of CISIZE ....................................................................................................... 8-168.2.2 Choice of INCRSIZE .................................................................................................. 8-168.2.3 Evaluating the pool size (POOLSIZE in command JCL: SIZE) ............................. 8-168.2.4 Relation between CISIZE and the type of disk ....................................................... 8-168.2.5 CREATE-FILE (interactive) utility ............................................................................ 8-17

8.3 "FOR INQUIRY" TRANSACTIONS ............................................................................ 8-17

8.4 "FOR DEBUG" TRANSACTIONS .............................................................................. 8-18

8.5 SHAREABILITY OF MONITORED FILES ................................................................. 8-18

8.5.1 Non concurrence ....................................................................................................... 8-188.5.2 Reminder concerning locks used by GAC .............................................................. 8-188.5.2.1 Shared read................................................................................................................. 8-188.5.2.2 Exclusive read............................................................................................................. 8-198.5.2.3 Statistical read............................................................................................................. 8-198.5.2.4 Write............................................................................................................................ 8-198.5.2.5 Recap.......................................................................................................................... 8-20

8.5.3 GAC Operating Parameters ...................................................................................... 8-208.5.4 Using the Table of Locked Pages ............................................................................ 8-218.5.5 Case Study ................................................................................................................. 8-218.5.5.1 Entering n record codes and modifying....................................................................... 8-218.5.5.2 Common read/update problem ................................................................................... 8-228.5.5.3 Problem of data entry .................................................................................................. 8-24

47 A3 56BB Rev02 1-1

1. Developing Transactional Applicationsunder GCOS7

1.1 TRANSACTIONAL APPLICATION: GENERAL INFORMATION

A transactional application is a GCOS7 application whose main purpose is to enable alarge number of users to access updated information through terminals scatteredthroughout a company and its various locations (offices, agencies, departments,workshops) in order to perform repetitive real-time operations within the company'sproduction system. This involves the processing of large volumes of data.

The available data is stored as a set of files or an IDS2 or ORACLE data base on a DPS7000 system or on several systems interconnected through a DSA/ISO-DSAtelecommunications network.

The operations performed by the terminal operators are called transactions. They allowthe stored data to be consulted, modified and created and may result in local or remoteoutput (invoices, reservations, dispatching notes) accordingly.

From the point of view of the people involved in transactional applications, it should benoted that the end users (who are also called terminal operators) are not computerexperts and use transactional applications as a tool for performing their daily work. Thework of the computer team is, after analysing needs, to program the transactions for theend users.

As the end user's work is done in "real-time", system response time is a key elementwhere transactional applications are concerned. This is why the structure of thetransactional application GCOS7 tool is based on performance and security.

ORACORP registered trademark

Transactional Applications under GCOS7TDS - SINDIA7 Overview

1-2 47 A3 56BB Rev02

1.2 STRUCTURE OF A GCOS7 TRANSACTIONAL APPLICATION

The end user has a certain job to perform and to do so he has at his disposalTRANSACTIONS which represent a logical processing unit: when he has finished runninga transaction he can initiate another one, independent from the first. The mansystemdialog during a transaction may involve several exchanges between the user and thesystem. For example, the user enters the transaction code, the system prompts forinformation, this information is entered, additional information is requested and so on untilthe end of the transaction.

From the technical standpoint, the logical processing unit of the TRANSACTION can bebroken down into several processing routines corresponding to the exchanges within thetransaction: they are called TPRs (transaction processing routines).

The user (in the simplest of cases) keys in the transaction code on the terminal: thesystem receives the code in the form of a message and activates the correspondingprogram. Activating a program involves allocating resources, managing the dialog with theuser (for example, in order to resume to within one screen page in the event of aninterruption in service), setting up safety features for concurrent access to data with otherusers. Resources are not kept from one transaction to another because, as transactionsare independent from each other, this would be meaningless. Furthermore, certainresources (although rare) are only allocated the time to use them and are then returnedas quickly as possible so that the other users can use them.

These functions are provided under GCOS7 by a special product called T.D.S.(Transaction Driven Subsystem). The name of this product is self explanatory: it is"driven" by the users' transactions. It acts as a server in order to execute transactions.

Developing TransactionalApplications under GCOS7

47 A3 56BB Rev02 1-3

1.3 TDS/GCOS7 FUNCTIONS

According to what has been explained thus far, a transactional application assumessystem-type jobs (handling various queries from terminal operators, schedulingprogramming routines "TPRs", allocating resources, security of concurrent access to thesame data, handling messages from and to the terminals).

The "on-line" component of the GCOS7 transactional application monitor handles most ofthe tasks which have just been described; it is called the TDS executive. Its job consists inturning control over to the processing routines (TPRs) which are programs written by thecomputer team to perform the required processing. The TDS monitor reduces thecomputer team's task by handling as many operations as possible. The computer team istherefore free to concentrate on analyzing and encoding the processing operations inCOBOL ANS. This encoding concerns terminal screen form management (CDSEND,CDRECEIVE) and the actual processing and sequencing of TPRs. From the technicalstandpoint, manufacturer code (TDS executive) and code written by the computerdepartment (the TPRs which make up the transactions) are interfaced. To provide therequired performance, TDS requires that a transaction be broken down into TPRsaccording to a certain structure. Data transfer is standardized. This guarantees the correctoperation of transactions.

To achieve an executable TDS, "off-line" components must be used to compile TPRs andlink them in a shareable module (SM), to declare files used as well as the degree ofsecurity assigned to them, to generate the TDS according to needs and finally to readythe shareable module for execution by loading it in the backing store.


1-4 47 A3 56BB Rev02

1.4 USING A TRANSACTIONAL APPLICATION GENERATOR

A transactional application generator is a software engineering tool specialized in creatingsuch applications.

SINDIA7 provides help at three levels:

a) when analyzing the problem: by proposing a systems design method,

b) when accessing entities specific to TDS: by directly handling a certain number offunctions (such as screen form setup), which means that an extensive knowledge ofTDS is not required,

c) when programming and deciding upon a method: because SINDIA7 offers a perfectbalance between the method of analysis and the underlying tools. By using SINDIA7tools, the task left to the programmer analyst is perfectly standardized andcalibrated, resulting in better performance.

SINDIA7 tools involve all the aspects of transactional application development:

• enhancement of the dictionary,• managing messages,• generating screens,• prototyping by dialog simulation,• TPR encoding,• generating transactions,• setting up integrated TDS's,• generating analysis files.


47 A3 56BB Rev02 1-5

The following chart explains the relations between the various functions.

S YS TE M SA N A LY S IS

S YS TE M SD E S IG N

D ICTIO NA R YEN H A N CE M E NT

S C R E E NG E N E R A TO R

M E S S A G EM A N A G E M EN T

TR A N S AC TIO NG E N E R A TO R

P R O TO TYP IN G

D O C U M E N TA TIO NU S ERC O D E

IN TE G R A TE D TD SS E TU P

S IND IA 7

TR A N SA C TIO N A LA P P LIC ATIO N


1-6 47 A3 56BB Rev02

1.5 GENERAL DESCRIPTION OF SINDIA7

SINDIA7 is itself a transactional product to which are associated tools which can belaunched from SINDIA7 or IOF.

We will first describe the method then explain how to use it. Simply remember that theprinciple behind development on SINDIA7 consists in generating TPR skeletons based ondata provided by the programmer analyst.

The latter enters the COBOL code, without worrying about communication statements(SEND/CDSEND, RECEIVE/CDRECEIVE), form calls and communication fieldsaccording to the following diagram.

C A LL C D R E C E IVE ...

P rocess ing

C A LL C D R E C E IV E ...

TD S se tuptransac tiong ene ra to r

S IN D IA 7

S IN D IA 7

P rocess ing

(6)

P rocess ing

C A LL C D S E N D ... N E X T TP R IS ...

C A LL C D S E N D ... N E X T TP R IS ...

S IN D IA 7

S IN D IA 7

S IN D IA 7

P rocess ing

(1)

(2 )

(1 )

(2 )

(5 )

(3 )(4 )

(3 )(4 )

As shown on the SINDIA7 operating diagram, the basic structure of a TDS/GCOS7application requires programming according to a predefined structure:

• screens (1), (3)• TPR sequences (4)• processing operations (2)• inter-TPR chaining is automatic with the Data dictionary (6)

Transactions are generated and TDS's are set up (5) according to specific rules too. Theleft-hand side of the diagram summarizes these points and the right-hand side showsSlNDIA7's part.


47 A3 56BB Rev02 1-7

By initiating the associated jobs, the transactions developed by SINDIA7 are added to theSINDIA7 development TDS. These transactions can then be debugged. The SINDIA7development TDS can then be promoted to the rank of operating TDS. You can also usetransactions developed by the SINDIA7 development TDS in a production TDS.

S IN D IA 7 -TD S

D E V E LO P M E N T

IN TE G R A TE

P R O D U C TIO N -TD S

E X P O R T

SINDIA7 has an on-line documentation feature intended for the end user and programmeranalyst. When developing applications under SINDIA7, the programmer analyst has thenecessary documentation on-line at his disposal.


1-8 47 A3 56BB Rev02

47 A3 56BB Rev02 2-1

2. The SINDIA7 Method

2.1 INTRODUCTION

The SINDIA7 method applies to each phase in the life of an application:

• analysis,• encoding,• use,• maintenance,• documentation.

The analysis phase consists in breaking a transaction down into basic exchanges and indescribing them. The exact definition of a basic exchange is given below. For themoment, it is enough to know that a basic exchange includes an operator's action (forexample, entering one or more values onto a form already displayed) and the processingof the values entered. The analyst uses a SINDIA7 analysis sheet to guide him: thisenables him to describe exchanges, their sequences and the forms used very naturally.

At this stage, it should be noted that the analyst will find a standard SINDIA7 organicanalysis file in the appendix to this manual.

This document is specially designed to be easily duplicated, providing a support for

• the transaction analysis method• help in developing the transaction• an organic analysis file development tool

The encoding phase consists in using specialized SINDIA7 transactions to key in thecontents of the SINDIA7 analysis sheet. The programmer analyst can then implement aprototype of his transaction in order to validate the man-machine dialog with the endusers. After this is done, he generates the skeleton of the transaction using SINDIA7, thenprograms the processing operations associated with each exchange. Any programmingmethod can be used (structured COBOL, JACKSON or LCP WARNIER) as the TPRskeleton is itself structured.

During the using phase, the end user is provided with standardized screens whichguarantees a consistent and foreseeable way of working within situations which frequentlyarise when using transactional work stations: normal end of transaction, cancellation oftransaction, on-line documentation request, screen form redisplay.

The programmer analyst has less work as far as programming is concerned since theseevents are handled in standard fashion by SlNDIA7's notion of command processingexchange.

Transational Applications under GCOS 7TDS - SINDIA7 Overview

2-2 47 A3 56BB Rev02

The programmer analyst can extend this notion to offer the end user any desirablefunction within the framework of standardized screens. This notion of commandprocessing exchange will be fully defined below.

2.2 ANALYZING A TRANSACTIONAL APPLICATION

Here is an example which will help to explain the SINDIA7 method of analysis. Theinformation provided in this section should be considered as training in this method, theactual implementation of this method, in other words the development of a transactionusing SINDIA7, is covered in the next chapter.

Description of the transaction

As an example let's take the development of a file query transaction called LIST specifiedas follows:

(1st exchange)

LISTThe en d user en ters L IS T

The system's response consists in displaying a form prompting the terminal operator toenter the reference of the object to be listed (form name: REF).

(2nd exchange)

REF :REF

The en d user en ters the re fe ren ce o f the ob jec t to b e lis ted .

If the reference is valid, the system responds by displaying the relevant data on theDET(ail) form (for the sake of simplicity, we shall assume that one screen is sufficient).

If the reference is invalid, the system responds by remaining in the REF form andinforming the terminal operator that the reference is unknown.

(3rd exchange)

Th e en d u ser rea ds the in form ation an d pre sse s TR A N S M IT/E X E C U TE toco ntinu e.

DETAILEDINFORM ATIO N....

DET

The system responds by returning to the conditions of exchange No. 2, in other words, theREF form is displayed.

etc.

The SINDIA7 Method

47 A3 56BB Rev02 2-3

Remark: As described, the script does not have an End sequence: inSINDIA7, normal transaction end (or cancellation) operations arealways done explicitly using the function referred to as the standardcommand function. From the terminal operator's standpoint, heenters "END" (F) in a specialized field of the SINDIA7 standardizedscreen which is sufficient to trigger the normal end of the currenttransaction.

The above description can now be completed as follows: "at the2nd and/or 3rd exchange: the terminal operator enters the standardcommand END (F) to terminate the transaction".

2.3 OUTLINE OF THE SINDIA7 ANALYSIS SHEET

109

5

8

432

76

1

T

O

Level Chaining

N° D/I

Descriptio nAuthor izedcom m ands

Pro cessingForm

Exchangeid

Nam e of COPYclauses linked to

processing

2.3.1 Exchange Identifier Column

Each item is identified by an identifier which is either a number (1 to 99) or a mnemonicfor command processing exchanges c


2-4 47 A3 56BB Rev02

2.3.2 Level Column

This column specifies the direction in which the line continues.

That is:

• either to an end user (also called operator) action (letter "0") d,

• or to a processing operation (letter "T" which stands for "traitement" in French whichmeans processing) h.

2.3.3 Operator action description (line marked "0" in "2")

• The programmer analyst specifies the name of the form attached to this exchange in e. If there is no form, for example for the first exchange of a transaction or for acommand processing exchange, this field remains blank.

• Authorized commands are listed in f.

• The end user's action is described in g.

2.3.4 Processing description (line marked "T" in "6")

• The COBOL paragraph name of the SlNDIA7-generated skeleton is specified in i.

PSIN1, PSIN2, ..., PSIN99 if the exchange identifier is a number.PSINFPSINABT

if a standard "END" command is involved (F).

if a standard "CAN" command is involved (cancellation) (ABT).

PSINX1, PSINX2, ..., PSINX99 for user commands (this notion is explained below).

• The exchange number to which the transaction chains is specified in j. Whenchaining is conditional, several numbers are required and the condition is specified in k.

NOTE: The notion of indirect chaining is explained below.

• The corresponding processing operation is described in k.

The SINDIA7 Method

47 A3 56BB Rev02 2-5

2.3.5 Name of COPY clauses linked to processing ("10")

Here, you list the Cobol "COPY" clauses linked to the processing operation, that is, thosewhich described the processing operation itself.

2.4 USING THE SINDIA7 ANALYSIS SHEET

Level Chaining

N° D/IDescriptionAuthorized

com m andsProcess

FormExchange

id

COP Y clauseslinked to the

processing op .

1

2

3

F

O

T

O

T

O

T

O

T

--

P S IN1

R E F

P S IN 2

D E T

P S IN3

--

P S IN F

all

C hain to exchange 2

Test the reference

C hain to exchange 2

E nd of transac tion

--

--

-- --

a ll

2P S IN1

2

2

3

The operator entersthe transaction code

The operator entersthe reference

R eference invalid: d isplaym essage and w ait for newrequest

R eference valid: getcorresponding inform ation

O perator readsdetails and chains tonew request using"TR A N S M IT/E X E C U TE "


2-6 47 A3 56BB Rev02

The SINDIA7 analysis sheet reads as follows

Exchange 1:

• The operator enters the transaction code and presses TRANSMIT/EXECUTE, whichtriggers the processing associated with exchange 1.

• The corresponding processing (COBOL paragraph: PSIN1) comes down to chain toexchange 2.

• Since exchange 2 uses attached form REF, SINDIA7 automatically sets up this formduring the chaining to exchange 2. SINDIA7 also displays a message which is attachedby default to exchange 2 (this message is stored in a file).

Exchange 2:

• The operator keys in the reference on the REF form, displayed on the screen, andpresses TRANSMIT/EXECUTE, which triggers the processing associated to exchange2.

• The corresponding processing (COBOL paragraph: PSIN2) checks the reference whichhas been keyed.

• If the reference is not a valid one, the processing chains to exchange 2 with a display ofa message pertinent to the error situation, instead of the message which is associatedby default with exchange 2. SINDIA7 knows that the REF form, associated withexchange 2 is already mounted. This form is consequently not mounted again.

• If the reference is valid, the processing retrieves the corresponding data, assignsvalues to the fields of the DET form, and chains to exchange 3. Since exchange 3 usesattached form DET, SINDIA7 automatically sets up this form. The fields of the DETform receive the values which have just been set. SINDIA7 also displays the messagewhich is attached by default to exchange 3.

Exchange 3:

• The operator reads detail data on the DET form and chains to a new request withTRANSMIT/EXECUTE, which triggers the processing associated with exchange 3.

• The corresponding processing (COBOL paragraph: PSIN3) comes down to chain toexchange 2.

• Since exchange 2 uses attached form REF, SINDIA7 (no matter what exchange youcome from to execute exchange 2) automatically sets up the REF form during thechaining to exchange 2. SINDIA7 also displays the message which is attached bydefault to exchange 2.

The SINDIA7 Method

47 A3 56BB Rev02 2-7

Standard Command "END" (F)

• It is allowed anywhere in the transaction (exchange 2, exchange 3) to end the dialog.

• The operator keys "END" (F), either at exchange 2 or 3, into a standardized field of theSINDIA7 screen, and presses "transmit/execute".

• SINDIA7 recognizes the command "END" (F) and chains to the attached processing(COBOL paragraph: PSINF).

• There is no particular processing to comment for this end of transaction: SINDIA7terminates the transaction.

2.5 CHAINING BETWEEN EXCHANGES

The programmer analyst defines the next exchange within the processing operationassociated with a particular exchange.

Chaining is controlled by SINECH, the exchange number symbolic counter. At thebeginning of an exchange, the value of this counter is equal to the number of the currentexchange.

To chain to another exchange at the end of the current one, you must assign the newnumber to SINECH.

MOVE n TO SINECH

NOTE: An error often made by beginning SINDIA7 programmers is to forget to assign anumber to SINECH. As this variable takes the number of the current exchange,nothing happens when "transmit/execute" is pressed: you remain in the sameexchange.

2.6 STANDARDIZING FORMS

SINDIA7 forms always have two parts:

• A SINDIA7 heading including 3 fields handled by SINDIA7 (heading 1). These aregenerally the first 3 lines, but the REMARK zone may be moved to the 24th line.

• A user heading including 22 lines at the user's full disposal (heading 2).

O R DE R :R E M A R K :

P A R A M E TE R :H ea d ing 1S IN D IA 7

H ea d ing 2U S E R

The SINDIA7 heading includes 3 reserved fields:


2-8 47 A3 56BB Rev02

• The ORDER field (8 characters) used to enter a command (a standard SINDIA7command or a user command) or the name of the next transaction to be run.

• The PARAMETER field (24 characters) used to enter the parameters of a command ortransaction named in the COMMAND field. It is also used to enter normal informationduring a transaction.

• The REMARK field in which help or error messages for the end user appear on aroutine basis. This field can only be accessed by program (a fixed addressable fieldaccording to SINDIA7 terminology). It should be remembered that in addition to theform attached to an exchange, a message, displayed in the REMARK field, is alsoassociated with the exchange. From a practical point of view, this association"exchange-form-message" is done when defining the exchange. The programmeranalyst may decide when programming the exchange to display a message other thanthe default message associated with the exchange in the REMARK field.

The function of the user heading is clear: it contains the user portion of the form.

The PARAMETER field as explained above can also be used to enter any user data.

The REMARK field can be parameterized. Its position can be modified when creating themessage.

2.7 SINDIA7 COMMANDS AND USER COMMANDS

The end user's productivity at his work station depends, to a large extent, on the workmethod which must be consistent and foreseeable in all its phases. SINDIA7 assists theprogrammer analyst in creating such an environment easily due to the notion ofcommands.

It should be noted that the programmer analyst logged on to SINDIA7 for developmentpurposes benefits under SINDIA7 development transactions from the same work method.

2.7.1 SINDIA7 Commands

The following functions are offered:

Normal end of transaction: initiated by the end user END command (F)

Transaction or processing cancellation CAN command (ABT)

On-line documentation consultation HLP command (SVP)

Form re-display (repeat) RPT command (BIS)

2.7.1.1 END Command (F)

This command results in the normal end of transaction which is always left to the enduser's initiative. The END command can be enabled/disabled dynamically: this makes it

The SINDIA7 Method

47 A3 56BB Rev02 2-9

possible to handle update sequences in which the normal end of transaction is to bedeferred. The END command is enabled by default.

The programmer analyst can run a specific end of transaction processing operation. If nospecific processing operation is defined, the END command results in the end of thetransaction.

2.7.1.2 CAN Command (ABT)

This command cancels the current processing operation. The end user is always allowedto use it.

The programmer analyst can run a special processing operation, for example, to abort acurrent operation and go on to another exchange in the transaction to begin anotherprocessing operation.

If no specific processing operation is defined, the CAN command results in the end of thetransaction.

2.7.1.3 HLP Command (SVP)

This command is a request to consult the on-line documentation associated with thecurrent execution context. The documentation is displayed on screen forms. The end userrequests the next page by pressing the TRANSMIT/EXECUTE key with the COMMANDfield either blank or containing " +".

To go back a page, the end user enters "-" in the COMMAND field and presses theTRANSMIT/EXECUTE key. To return to the status before having made the request foron-line documentation, the end user enters "R" (for return) in the COMMAND field andpresses the TRANSMIT/EXECUTE key.

The HLP command is only meaningful if the relevant on-line documentation exists. Theprogrammer analyst is in charge of creating it and can define up to 99 document formsper transaction. From the programming standpoint, the mechanism for on-line documentrequest, consultation and return is fully handled by SINDIA7 and does not require anyprogramming.

Let us note that the on-line documentation of the SINDIA7 development transactions ismade accessible to the analyst- programmer by the same HLP feature.


2-10 47 A3 56BB Rev02

2.7.1.4 RPT Command (BIS)

The SINDIA7 Method

The RPT command is used to re-display the current screen form: this function is usefulwhen the terminal operator detects a mistake in what he has just entered, and feels itwould be easier to return to the beginning of the exchange with a fresh form rather thancorrect the data already entered item by item.

The RPT command is always authorized and is invisible as far as programming thetransaction.

2.7.2 User Commands

The programmer analyst may define commands and add them to the standard ones. Thisprovides a greater degree of friendliness for the end user which is both efficient and directas far as the SINDIA7 developer is concerned.

For example, if a transaction (STOCK) is logically divided into several independentsubfunctions, it will be easier for the user to go from one subfunction to the other bysimply entering a user command in the ORDER field (e.g. C for Create, M for Modify, Qfor Query and D for Delete). If, moreover, the same conventions are kept from onetransaction to another, the end users' training is made easier.

As far as programming is concerned, the tasks involved are as follows:

• The command mnemonics must be declared: this is done with the help of the SINDIA7GESTRX transaction definition transaction,

• The command entered by the end user must be recognized and there must be abranch to the COBOL processing paragraph: this is handled automatically by SINDIA7.

• Actual programming must be done: this is up to the programmer analyst.

There can be as many as 99 user command definitions per transactions.

To increase dialog efficiency, it is possible to pass parameters at the same time as thecommand is entered (PARAMETER field on the screen, the value of which is received inthe program variable SINPAR).

Moreover, some commands in a particular transaction may only be meaningful within aspecific context (for example in some exchanges and not in others): the programmer canenable or disable access to one, several, or all user commands.

As an additional feature to the command function, the terminal operator can enter atransaction code in the ORDER field (even including parameters in the PARAMETERfield, received in SINPAR in the program). This is a short cut for:

• Normal end of transaction and execution of associated processing operation, as iftyping in END (F),

• Chaining to the relevant transaction

The SINDIA7 Method

47 A3 56BB Rev02 2-11

2.7.3 Function keys linked to a command

It is possible to link a standard command or user command to a function key.

To do this, three operations must have been performed when the transaction wasdeveloped.

a) the screen form linked to the command processing exchange has to have beencreated, declaring the functions keys to be used (see user manual, GESGRItransaction).

b) the linked command has to have been authorized for this exchange, using "MOVESINOK TO SXXX".

c) when creating under GESTRX, the function keys used should be declared.

2.7.4 User Command: An Example

Let's analyze and develop a transaction, LISTA (list station), as follows:

The transaction will involve listing information associated with a station. This informationtakes up one or more screens. We will use the same form (X005) to output theinformation on the station.

When the display of information pertaining to one station is finished, the user can requestthe same type of information for another station by entering a (new) station code in thePARAMETER field. The user has the DEB command at his disposal at all times to returnto the beginning of the information display for the current station. In addition, the DEBcommand accepts a parameter (a code) used, not to resume the display from thebeginning, but from this code for the current station.

Here we will go into some further explanations on the analysis which was made.

Two exchanges have been used, both using the same attached form. It would have beenpossible to do only one exchange, but it would have been complicated to program.Exchange No. 1 is mainly used to describe the state in which we "end up": either it is theend of the list or all the data fits on one screen. Once we are in exchange No. 1, we areready to process a new station code or exit from the transaction (END-F). Exchange No. 2represents an iterative state in which it is not yet the end of the current data display.


2-12 47 A3 56BB Rev02

XCH

LEV

SC REEN/

PRO C.

AUTHORIZ EDOP E RATORCOM MANDS N° D/I

CHAIN ING DESCRIPTIONOF THE

EXCHANGE

1

2

O

T

O

T

X 005

P S IN 1

X 005

P S IN 2

D E B

D E B

12

12

TH E O P E R AT O R E N TE R S AST A TIO N C O DE IN P A R A M E TE RFIE LD O R N O T

PA R A M E TE R FIE LD AN A LYS IS := C O D E TH E N LIST D IS P LA YE D FR O M TH IS C O D E= B LA NK TH E N LIS T D IS P LA YE D FR O M B E G IN N IN G - E N D O F LIS T - N O T E N D O F LIS T

TH E O PE R A TO R E N TE R S AS TATIO N C O D E IN P A R A M E TE RFIE LD O R NO T

PA R A M E TE R FIE LD AN A LYS IS := C O D E TH E N LIST D IS P LA YE D FR O M TH IS C O D E= B LA NK TH E N N EX T D A TA D IS P LA YE D - E N D O F LIS T - N O T E N D O F LIS T

Another point deserves to be noted: in exchange No. 1, we have attached form X005, onemust realize what this means and at what time this form is set up. To explain this we shalldescribe a dialog.

The SINDIA7 Method

47 A3 56BB Rev02 2-13

Th e u se r a ctiv a tes L IS TA from the la s t sc re en o fa no the r tra ns ac tion (fo r e xa m ple S TO C K )

W e n ow e nter th e pro ce ssing o p eratio n for excha ng eN o .1 o f LlS TA . W e ca n acc e ss the d ata o f s tat io n N N N .W e p re p are th e f ie lds for dis p lay pu rpo ses .

If it is th e e nd o f th e lis t, w e ch a in to e xch ang e 1 ( i.e .w e re m ain in th e s am e e xch an g e) retu rn ing con tro l toS IN D IA 7 w hich se ts up form X 0 05 a tta che d toe xch an g e 1 a nd d ispla ys the in form ation .

If it w a sn't the end of the list, w e w ou ld h av e chaine d toe xch an g e 2. This cha inin g is w h at se ts up form X 0 05a tta ch ed to e x cha ng e 2 a nd d isp lays the in fo rm atio np rep ared du rin g e xch an g e 1.

L IS TA N N N

la s t s c re en

- S TOC K -

-- X 0 05 ---- - - - --- - - - -(e nd o f sta tio n N N N )

X 0 05 - s ta tion N N N -

E x cha ng e 2

E x cha ng e 1

Now we can go back to the LIST transaction we described earlier in Analyzing aTransactional Application and take advantage of the parameter field in order to economizetwo exchanges. Let's specify LIST as a transaction which is activated and to which wepass the code of the object to be listed (in the PARAMETER field). If the code is valid, thesystem responds by displaying the corresponding information on the DET(ail) form, then itwaits for a new request concerning another station (in the PARAMETER field).

If this code is not valid, the system displays an error message and an "empty" DET form(the variable fields contain no values).

We exit from the transaction using the standard command "END" (F).


2-14 47 A3 56BB Rev02

The transaction can be programmed in a single exchange. LIST transaction: Example ofprogramming in a single exchange.

Exchangenumber

Level Processform

Chain Description

1 O DET The operator enters thecode of a station in thePARMETER field, or exitsfrom the transaction (END)

T PSIN1 1 If parameter field emptysystem prompt to:- enter the code in the PARAMETER field- end of exchange.If parameter field notempty, information issearched for:- if code error: error message- if code OK: preparethe data to display- end of exchange

2.8 PROGRAMMING COMMAND TRANSACTION EXCHANGES

The processing operations related to standard commands END (F) and CAN (ABT) aredescribed in the PSINF and PSINABT COBOL paragraphs.

The CAN (ABT) command is always enabled so that the end user has a systematic wayof cancelling a processing operation.

The END (F) command is enabled by default but can be disabled. The initial value of itsenable flag, called SF, is SINOK. By executing:

MOVE SINNO TO SF

The END (F) command is disabled.

The mnemonics of the user orders are stored in a table at TPR definition time. Thecorresponding processing is done in COBOL paragraphs whose names are PSINXi,according to their rank "i" in this table.

The names of their enable flags are:

S"command name"

By default, the user commands are disabled (the attached enable flag holds the SINNOvalue).To enable them, one codes

The SINDIA7 Method

47 A3 56BB Rev02 2-15

MOVE SINOK TO S"command name"

When programming the commands, one accesses the values from the PARAMETERarea in the SINPAR variable. To chain from an order to an exchange of level "i", oneneeds to assign the exchange counter SINECK.

2.9 RECAP: I LEVEL EXCHANGE

The i level exchange involves:

• Entering data on the terminal (operator action),

• Receiving this data (CDRECEIVE primitive executed by SINDIA7) via a screen form,

• The associated processing,

• Sending the response to the terminal (CDSEND primitive executed by SINDIA7).

• "i"-LEVEL EXCHANGES ARE THE ONES WHICH HANDLE SCREEN FORMS.

2.10 RECAP: COMMAND PROCESSING EXCHANGE

These exchanges initiate an action when they are entered; they receive data only from thePARAMETER field (SINPAR). They can chain to an i-level exchange (MOVE ... TOSINECH).


2-16 47 A3 56BB Rev02

2.11 OPTIMIZATION: NOTION OF INDIRECT EXCHANGE

This notion is explained using an example.

It illustrates how the command notion can simplify programming.

The example involves designing a transaction for data entry. The classical problem forsuch an application concerns the end user validating the data which he has just entered.Experience shows that if asked systematically to validate, the end user also tends tovalidate systematically, so a cancel transaction must be anticipated.

SINDIA7 offers an elegant and efficient solution to this type of problem: validation isimplicit; entering new data implicitly validates the previous data. To cancel data entered,the user must take explicit action. This method involves two exchanges: data are actuallywritten one exchange behind, so if the end user wants to cancel the writing procedure, allhe has to do is use the standard CAN command.

TR A N S A C TIO N C O D E IS E N TE RE D

S TA TIO N D A TA IS E NTE R E D INH E A D IN G 2 O F TH E FO R M

D A TA R E C E IV E D A ND C HE C K E D

- IF A T LE A S T O N E E R R O R : M E S S A G E 0011- IF N O E R R O R

O P E R A TO R E N TE R S S TA TIO ND A TA IN H E A D IN G 2 O F THE FO R M

D A TA R E C E IV E D D U R IN GP R E V IO U S E X C H A N G E 3 ISW R ITTE N

XCH

LEV

SC REEN/

PRO C.

AUTHORIZ EDOP E RATORCOM MANDS N° D/I

CHAIN ING DESCRIPTIONOF THE

EXC HANG E

1

2

3

O

T

O

T

O

T

2

2

3

2

1

The chain column features the subdivision "D/I".

D stands for direct: this is the default value and has not yet been covered.

I stands for indirect: it is used here.

The SINDIA7 Method

47 A3 56BB Rev02 2-17

Indirect chaining between two exchanges is only meaningful if they have the same formattached. In this case, after the first of the two exchanges is processed in COBOL,SINDIA7 chains to the other exchange, for COBOL processing, without a request foraction on the part of the end user. This is called an "indirect" call to this exchange.

Let's go back to the example: exchange 3 includes indirect chaining to exchange 2.Therefore, after PSIN3 is executed, SINDIA7 chains to PSIN2 in exchange No. 2 withoutasking for new data to be entered.

The sequencing works as follows: the user enters data in exchange 3 (time T). Thisimplicitly validates the data which were previously entered (time T-1), they are then stored.The program indirectly chains to exchange 2, in other words, SINDIA7 turns control overto PSIN2 where the data entered in exchange 3 (time T) are checked. If the data arecorrect, the program chains to exchange 3: the terminal operator is prompted to enter newdata (T + 1). Entering these data implicitly validates the previously entered data and soon.


2-18 47 A3 56BB Rev02

47 A3 56BB Rev02 3-1

3. Administrative Management of Project andUser Profiles

3.1 THE ROLE OF THIS FUNCTIONALITY

This functionality is intended to meet the following needs for:

• management, by project, of the SINDIA 7 objects that result from the developmentphase

• verification of the development users' rights regarding the SINDIA 7 objects accordingto the projects involved

• verification of the development users' rights regarding the actions possible in thevarious transactions of the SINDIA 7 development tool

During the development phase, the "Management of the Objects by Project" offers usersthe services listed below:

• identification, at project level, of the set of SINDIA 7 objects handled by the differentusers of a given project

• management (creating, modifying, deleting, displaying) of these objects at the level ofthe project itself

• referencing of these objects by project in the dictionary

• guarantees the confidentiality of a project's objects as far as other projects areconcerned by means of access rights

• groups in a common project the common objects of the SINDIA 7 environment liable tobe used by all the applications

• authorization of users working under a given project to access objects located inanother project, or in the common project, in order to read them

• authorization of the transfer of a project's objects from a development project to a testor production environment

This functionality is provided by setting up a specific "Profiles" file managed by the"Administrative Management of Profiles and Users" transaction.


3-2 47 A3 56BB Rev02

To install and use this function in SINDIA 7 the corresponding "Marketing Identifier" keymust be validated.

3.1.1 Project Definition

To be recognized by SINDIA 7, the project must be declared in the profiles file using the"Administrative Management of Projects and Users" function.

The project is identified by its name and an associated code made up of 3 alphanumericcharacters, the first of which must be alphabetic. This code is used internally by SINDIA 7to manage the objects. It must be unique for a project, two separate projects cannot havethe same code.

The Profiles administrator determines this code, but SINDIA 7 checks that the code doesnot exist already for another project whenever a new project is created.

The project name may be the same of as the name declared in the GCOS 7 catalog, butthere is no link between the GCOS 7 catalog and the SINDIA 7 user profile.

The following definition data is attached to the project:

• the nature of the project

• the values of the default characteristics applicable in the screen form managementtransaction (GESGRI)

• a code indicating whether the project status is "active" or "inactive"

The values of the default characteristics defined for the project will be applied to the userslinked to this project for whom no other values were explicitly defined when their userprofile was created.

The number of projects which can be declared under SINDIA 7 is theoretically limited tothe number of possible combinations of the three characters constituting the associatedproject code. However, for practical performance reasons, the maximum number ofprojects which can be supported by a given SINDIA 7 TDS is 512. Furthermore, the"active project" concept has been introduced, which describes projects all the differentusers can access as long as they have the corresponding rights.

The maximum number of simultaneously active projects is 32.

When a project is created, it is automatically set to inactive status.The project's "active" or "inactive" status can then be modified by the profiles

administrator using the Administrative Management transaction.

Administrative Management ofProject and User Profiles

47 A3 56BB Rev02 3-3

Users cannot indicate an inactive project as their working project, even if the rights for theproject are defined for them in their profile. If they try to do so, they will be informed of theanomaly and no action will be authorized for them in the various SINDIA 7 tooltransactions, except for the transaction used to modify the working context.

However, an inactive project can be declared in the list of projects whose objects areaccessible to a user. The project must then be activated for the user to be able to accessthe objects in the project.

3.1.2 User Definition

To be able to use the SINDIA 7 transactions in the development tool and access theobjects, every development user must be declared in the profiles file.

A user is identified by his/her name and an associated password. These may be the sameas those declared in the GCOS 7 catalog; but there is no link between the catalog andSINDIA 7.

The user name and password are requested and checked when the user logs on, but onlyif the Management of Users and Profiles transaction has been validated on the site. Thischeck is performed by a specific TPR activated by the LOGON TPR.

IMPORTANT

The standard name of the user defined as the administrator is SINDIAand the standard password is SINDIA: this user has his/her own profilewhich can be modified.

The following profile data is associated with the user:

• general data independent of the project to which the user is attached:

- the default language code (0=English, 1=French)

- the default principal project

- the default secondary project

- the projects for which this user has the right to access the objects. This right maypermit reading/writing or reading only. There are no access rights for writing only.

• data specific to the associated project to which the user is attached. For eachassociated project, this involves:

- the list of the development tool transactions authorized for this user

- for each of the authorized transactions, the list of the actions authorized for the userwithin the transaction


3-4 47 A3 56BB Rev02

- the values of the default characteristics applicable in the screen form managementtransaction (GESGRI). These values take priority over those defined at the projectlevel. When no values are defined for the default characteristics at user level, theproject-level values are applied to the user

A principal project and a secondary project are defined for each user.

• The principal project is the working project under which the user can create, modify anddelete objects from, as long as he/she has been granted the corresponding rights. Theuser must therefore have read/write rights concerning the objects in this project.

• The secondary project is the project in which the user can only access the objects toread them during a given transaction of the development tool.

The conditions for declaring these different projects in the user's working environment aredescribed in the paragraph dealing with the relations between user, project and objects.

3.1.3 Object Definition

The term "object" is used here to describe the set of components used in thedevelopment of an application transaction:

• labels• structures• screen forms• messages• programs• commands• COBOL copy instructions• files, IDS2 areas and ORACLE tables• scenarios

SINDIA 7 objects are not defined in the profiles file. Their description is recorded in thecorresponding SINDIA 7 work files, or in the dictionary in the case of labels or structures.

Each object is identified by its name together with the code of the project under which itwas created. This is the principal project under which the user was connected when theobject was created. This (principal) project therefore becomes the owner of the project orobject. SINDIA 7 establishes the link between the object and its owner. This link cannotbe modified once it has been established.

Thus, two objects with identical names but belonging to different projects constitutedistinct objects.

This structure of the SINDIA 7 data means that it is possible to manage different versionsof the same object.

The reference of an object in the dictionary takes into account the owner project andprojects that use the object.

SINDIA 7 objects that predate the implementation of object management by project areattached to the common project. This is also the default mode if the "Management byProject" option is validated on the site.


47 A3 56BB Rev02 3-5

The name of the common project is SIND-COM. It is known to SINDIA 7 and does nothave to be created using the project management transaction.

3.1.4 The Relationships between User, Project and Objects

These relationships describe the management rules defining the links to be establishedbetween a user connected to a project and the objects which he/she can access.

• A user may be known in several projects, but in the development phase, during theimplementation of a SINDIA 7 tool transaction, the projects defining his/her workingenvironment are:

- the principal project in which the user can access the objects in read/write mode, aslong as the corresponding rights have been defined

- the secondary project in which the user can access the objects in read mode only

- the common project whose objects all users can access in read mode

• When users log on, if they do not indicate the project under which they wish to work,they are directly connected to the default principal and secondary projects declared intheir profile. If no default projects were declared in their profile, they will be asked toindicate this information.

• The user can modify the principal and/or secondary project by entering the "MDCTX"command in the command field of the SINDIA 7 screen. This modification must only beperformed at the beginning of a transaction.

• The objects belonging to the common project can be accessed by all users in readmode, but they can only be created, modified or deleted by an authorized user who hasdeclared the common project as the principal project in his/her working environment.

• A user can only create, modify or delete objects belonging to the principal project underwhich he/she is connected.

• A user can duplicate any object belonging to another project which he/she is authorizedto access.

3.1.5 Use of the Objects during the Development Phase

In an application transaction, objects such as the screen forms, messages, COBOLCOPY instructions or structures used by the transaction are declared within thetransaction by means of their identifier which contains the code of the owner project.

SINDIA 7 will automatically associate the project code with the name of the object used.

Example:


3-6 47 A3 56BB Rev02

The user "UT1" connected to the principal project "PROJ7" creates the transaction"MYTRX5" which uses screen forms GR01, GR02 and GR03 (these must have beencreated under this project).

The project's internal SINDIA 7 is "PJ7".

In the table of exchanges for this transaction, the screen forms will be declared asfollowed:

PJ7GR01PJ7GR02PJ7GR03

In a given TDS application, any TPR name or transaction name must be unique. InSINDIA 7, each of these objects is linked to the principal project under which thedeveloper was connected when they were created. These objects are therefore identifiedby their name, associated with the internal code of the project, but SINDIA 7 checks in thedictionary that there are no transactions or TPRs with the same name defined for otherprojects.

During the development phase, a user of a project may be led to create an object on thebasis of a similar existing object in his/her project or another project. This is calledduplication.

This action is governed by the following rules:

• If the owner of the object to be duplicated is the principal project under which theuser is connected, the user simply indicates the name of the object as known tohim/her (example: screen form GR01).

• If the owner of the object to be duplicated is the user's secondary project, he/shemust enter the character ";" (semi-colon) in the specific field "original project"associated with the name of the object (e.g. screen ;GR01).

• If the owner of the object to be duplicated is the common project, the user mustenter the character "!" (exclamation mark) in the specific field "original field" (e.g.screen !GR01).

• Otherwise, SINDIA 7 will apply the following search rules to the reference object tobe duplicated:

1. it will search the user's principal project2. it will search the user's secondary project3. it will search the common project4. it will transmit the message "object does not exist"

The duplication operation only applies to the reference object. If any objects used by thereference object are declared within the object, they are not duplicated. There is noinheritance of the reference object's tree structure.

Example:

The user "UT9" connected to the principal project "PROJ2" and the secondary project"PROJ7" creates the "MYTRX9" transaction by duplicating the "MYTRX5" transactionfrom the "PROJ7" project.


47 A3 56BB Rev02 3-7

Only the data involved in the description of the transaction will be duplicated in thecorresponding file. The screen forms, messages and other objects described under the"MYTRX5" transaction are not copied into the "PROJ2" project.

To be able to use them with the "MYTRX9" transaction, the user must create them byduplicating the corresponding objects in the "PROJ2" project and then modifying thetransaction thus created in order to re-establish the links between the objects in thetransaction and the project.

An object created by duplication in reference to another object located in another projectconstitutes an object that is distinct from the reference object, even if the name given tothe created object is identical to that of the reference object.

Duplication with an identical name is prohibited for application transactions and TPRswhose names must be unique within a given TDS. It is also prohibited for objects withinthe same project.


3-8 47 A3 56BB Rev02

3.2 TRANSACTION FOR ADMINISTRATIVE MANAGEMENT OF PROJECTSAND USERS

This transaction is used to enter the parameters defining the Projects and Users and toenhance the administrative management file containing their description.

This transaction is called GESADM. It can only be implemented if the "ProfileManagement" function of SINDIA 7 has been validated on the site.

Normally, it can only be used by the user defined as the profiles file administrator, buthe/she can authorize other users to access this transaction. It is also possible to authorizeother users to execute all or some of the actions available in the GESADM transaction.

There is also a privileged user with all the rights who can create the administrator whenthis function is implemented for the first time.

3.2.1 Functions Offered by the GESADM Transaction

The transaction offers two main functions:

• Project Management• User Management

When the administrative management function is implemented, the Projects must bedeclared before the Users. When you describe the Projects authorized for a User, thetransaction checks that the Project has been created correctly.

The function is chosen in the general menu screen (screen AD01) presented to the userafter input of the transaction name.

The transaction requests and checks the user's name and password before verifyinghis/her rights.

3.2.2 "Project Management" Function

This can be used to manage the data describing a Project and its characteristics.

This function permits the following actions:

Project CreationProject ModificationDisplay of the data of a ProjectList of the Projects and their activation statusList of the Users of a ProjectList of the SINDIA 7 Project codes already assigned

The required action is chosen by entering the corresponding code in the command field ofthe menu screen of the PROJECT MANAGEMENT function (screen AD02).


47 A3 56BB Rev02 3-9

With the modification, display and list commands, it is also possible to enter the Projectname as a parameter.

3.2.2.1 Creation of a Project

This function corresponds to the "CRP" command in the Project Management menu. Itinvolves the following steps:

Step 1 (screen AD04)

*** SCREEN: AD04 COMMAND %%%%%%%% PARAMETER %%%%%%%%%%%%%%%%%%%%%%%% REMARK ////////////////////////////////////////////////////////////--------------------------------------------------------------------------------

PROJECT CREATION

Project Name : %%%%%%%%%%%%

Internal SINDIA7 code: %%%

Nature of Project : %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

AD04***

Indication of the Project name, the internal SINDIA 7 code and the Nature of the Project.

A check is performed on the SINDIA 7 code in order to verify that:

• the first character is alphabetic• the code is unique and has not been assigned to another project


3-10 47 A3 56BB Rev02


*** SCREEN: AD06 COMMAND %%%%%%%%. PARAMETER %%%%%%%%%%%%%%%%%%%%%%%%. REMARK ////////////////////////////////////////////////////////////-------------------------------------------------------------------------------- CREATION OF PROJECT //////////// DEFINITION OF DEFAULT CHARACTERISTIC VALUES USED TO GENERATE THE SCREEN FORMS

- WORKING MODE USED IN THE TRANSACTION : ............................... %. ( Global Mode = 1 , Detailed Mode = 2 )

- TYPES OF TERMINAL GENERATED: - VIP 7760 .. %. - DKU 71XX-72XX .... %. - VIP 78XX .. %. - Minitel .......... %. - IBM 3270 .. %. - PC7800 Emulation . %.

- DEFINITION CHARACTERS : - Variable field ............ %. - Addressable fixed field ... %. - Line repetition ........... %.

- Use of function keys ....................... %. - FORMS "RECEIVE SPACE" option ............... %. - FORMS "DECIMAL POINT" option ............... %. - Currency symbol ............................ %. - Prefix of symbolic names ................... %%%%. AD06

This involves defining the parameters of the default characteristics used in the screenform management transaction (GESGRI).

These values defined at Project level will be transferred to the users created under thisproject for whom default values have not been defined for the characteristics used inGESGRI.

This concerns the following parameters:

• the working mode used in the GESGRI transaction itself:- the value 1 corresponds to the global mode- the value 2 corresponds to the detailed mode

• the types of terminal for which you wish to generate application screen forms:- value 0 = no generation for this type of terminal- value 1 = generation for this type of terminal

• the definition characters used when constructing the design of the screen form

• the generation options (use of function keys, Receive Space, Decimal Point):- value 0 = function not implemented- value 1 = function implemented

• the prefixes for the symbolic names

The program checks the validity of the values entered. If there are any anomalies, anerror message is displayed in the "REMARK" field.


47 A3 56BB Rev02 3-11

3.2.2.2 Modification of a Project

This function corresponds to the MDP command in the Project Management menu.

It involves the following steps:



MODIFICATION OF A PROJECT

PROJECT NAME : .%%%%%%%%%%%%.

Enter "1" to select the type of modification. (Multiple choice authorized)

Nature of Project ......................... %.

Values of Default Characteristics ......... %.

Activation ............................... %.

AD11

This is a sub-menu designed to make the modification function flexible and ergonomic.

The user selects the type of modification required by entering the value 1 in thecorresponding field.

Multiple choices are possible and only the steps corresponding to the selected actions willbe presented to the user.


3-12 47 A3 56BB Rev02



MODIFICATION OF THE NATURE OF A PROJECT

Project Name : .////////////.

Internal SINDIA7 code : .///.

Nature of Project : .%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%.

AD07

This is used to modify the text describing the nature of the Project whose name andinternal SINDIA 7 code are displayed on the screen.

Modification of the project's internal code is prohibited as it would lead to inconsistenciesin the cross references between the objects and their associated project in the dictionary.







This is used to modify the values assigned to the parameters describing the defaultcharacteristics used in the application screen management transaction (GESGRI).

The authorized values and the checks performed are identical to those defined in theparagraph concerning "creation of a project".


47 A3 56BB Rev02 3-13



MODIFICATION OF A PROJECT'S ACTIVATION STATUS

Project Name : ////////////

Nature of Project : ////////////////////////////////////////

Internal SINDIA7 code of Project : ///

Operation on Project Status : %. ( A = ACTIVATION , D = DEACTIVATION )

AD10

This is used to modify a project's "ACTIVE" or "INACTIVE" status.When a project's status is set to "ACTIVE", the transaction checks that the number ofsimultaneously active projects is not greater than 32.

If it is, a message informs the administrator.

The project can only be reactivated after setting other unused projects to inactive status.

Authorized values:

A = ACTIVATION of the ProjectD = DEACTIVATION of the Project


3-14 47 A3 56BB Rev02

3.2.2.3 Displaying a Project

This function corresponds to the "VIP" command in the project management menu.It is used to display the data concerning a project.The function involves the following steps:



DISPLAY OF A PROJECT

Project Name : %%%%%%%%%%%%.

Nature of Project : ////////////////////////////////////////

Status of Project : ////////////

Internal SINDIA7 code of Project : ///.

Enter Y or "O"(letter) or "1" to view the default parameters used to generate the screen forms for this project ---------------> %.

AD09

Displays:

• the project name• the nature of the project• the status of the project (ACTIVE or INACTIVE)• the project's internal SINDIA 7 code

To display the information in the next step, the user must enter 1 or Y or O (letter) in thecorresponding field on the screen.

If the user does not do so, display of the project stops at step 1.


47 A3 56BB Rev02 3-15







Display the default characteristics parameters used in the screen managementtransaction and defined at the project level.

3.2.2.4 Project List

This function corresponds to the "LSP" command in the project management menu.

It provides a list of projects with an indication of their nature and activity status.

The list can be restricted to the project names contained within a defined range.

It is possible to select a project in the list and display details of the project's characteristics(equivalent of the display function).

The function involves the following steps:


3-16 47 A3 56BB Rev02



LIST OF PROJECTS AND THEIR ACTIVATION STATUS

Identifier of first project in list : %%%%%%%%%%%%.

Identifier of last project in list : %%%%%%%%%%%%.

Type of projects to be selected in list : %. ( A = ACTIVE D = NON-ACTIVE, * = ALL )

AD14

Enter the project names defining the search interval.

If there is no identifier defining the beginning of the list, it starts at the beginning of the fileand ends with the identifier defining the end of the list.

If there is no identifier defining the end of the list, it ends at the end of the file.

It is possible to limit the list to the projects with the activity status indicated in thecorresponding field on the screen.

A -> the list only contains the active projectsD -> the list only contains the inactive projects* -> the list contains both active and inactive projects

(default value)


47 A3 56BB Rev02 3-17


*** SCREEN: AD12 COMMAND %%%%%%%% PARAMETER %%%%%%%%%%%%%%%%%%%%%%%% REMARK ////////////////////////////////////////////////////////////-------------------------------------------------------------------------------- LIST OF PROJECTS WITH ACTIVATION STATUS

ROW PROJECT NATURE OF PROJECT SIND STAT NO. CODE CODE

// //////////// //////////////////////////////////////// /// / // //////////// //////////////////////////////////////// /// / // //////////// //////////////////////////////////////// /// / // //////////// //////////////////////////////////////// /// / // //////////// //////////////////////////////////////// /// / // //////////// //////////////////////////////////////// /// / // //////////// //////////////////////////////////////// /// / // //////////// //////////////////////////////////////// /// / // //////////// //////////////////////////////////////// /// / // //////////// //////////////////////////////////////// /// / // //////////// //////////////////////////////////////// /// / // //////////// //////////////////////////////////////// /// / // //////////// //////////////////////////////////////// /// /

To view details of a project, indicate the number ------------------> %%. AD12

Display the list of projects with indication of the project's rank in the list, name, nature, SINDIA 7 keycode and activity status.

You can display the information concerning a specific project by entering the rank numberof the project in the corresponding field on the screen.

3.2.2.5 List Project Users

This function corresponds to the "LUP" command in the profile management menu.

It can be used to display a list of the known users of the project specified.

It is possible to display detailed information concerning a user by selecting the user in thelist (equivalent of the consultation function in the User Management menu).

This function involves the following steps:


3-18 47 A3 56BB Rev02


*** SCREEN: AD13 COMMAND %%%%%%%% PARAMETER %%%%%%%%%%%%%%%%%%%%%%%% REMARK ////////////////////////////////////////////////////////////-------------------------------------------------------------------------------- LIST OF USERS BY PROJECT

Project Name : %%%%%%%%%%%%. Nature of Project: ////////////////////////////////////////

Number USER NAME Number USER NAME

// //////////// // //////////// // //////////// // //////////// // //////////// // //////////// // //////////// // //////////// // //////////// // //////////// // //////////// // //////////// // //////////// // //////////// // //////////// // //////////// // //////////// // //////////// // //////////// // ////////////

To view details of a user, indicate the number ------------------------> %%. AD13

Input of the project name.

This step is not presented to the administrator if he/she accesses this function byselecting the "LUP" command and indicating the project name in the parameter field ofthe menu screen.


*** SCREEN: AD13 COMMAND %%%%%%%% PARAMETER %%%%%%%%%%%%%%%%%%%%%%%% REMARK ////////////////////////////////////////////////////////////-------------------------------------------------------------------------------- LIST OF USERS BY PROJECT

Project Name : %%%%%%%%%%%%. Nature of Project: ////////////////////////////////////////

Number USER NAME Number USER NAME

// //////////// // //////////// // //////////// // //////////// // //////////// // //////////// // //////////// // //////////// // //////////// // //////////// // //////////// // //////////// // //////////// // //////////// // //////////// // //////////// // //////////// // //////////// // //////////// // ////////////

To view details of a user, indicate the number ------------------------> %%. AD13

• Display of a list of the known users of the project with indication of the name andthe rank in the list.

• It is possible to display the profile information concerning a user by entering theuser's rank number in the corresponding field.


47 A3 56BB Rev02 3-19

3.2.2.6 List of Project Codes Assigned

This function corresponds to the "LCP" command in the profile management menu.It can be used to display a list of the SINDIA 7 key codes already assigned to projects.The list can be restricted to a given code interval. The function involves the followingsteps:



LIST OF INTERNAL SINDIA7 PROJECT CODES AND ASSOCIATED PROJECTS

Identifier of first project in list : %%%.

Identifier of last project in list : %%%.

AD15

Input of the codes defining the beginning and end of the search interval.

If no code is entered for the beginning of the list, it starts at the beginning of the file andends with the identifier defining the end of the list.

If no code is entered to define the end of the list, it ends at the end of the file.


3-20 47 A3 56BB Rev02



LIST OF ASSIGNED INTERNAL SINDIA7 PROJECT CODES

SINDIA7 Code Project Name SINDIA7 Code Project Name of Project of Project

/// //////////// /// //////////// /// //////////// /// //////////// /// //////////// /// //////////// /// //////////// /// //////////// /// //////////// /// //////////// /// //////////// /// //////////// /// //////////// /// //////////// /// //////////// /// //////////// /// //////////// /// //////////// /// //////////// /// //////////// /// //////////// /// //////////// /// //////////// /// //////////// /// //////////// /// //////////// AD16

Display of a list of the project codes with indication of the project name.

If the list covers more than one screen, the rest of the list can be displayed by pressing"TRANSMIT".

The list can be aborted by entering "ABT" in the screen's "COMMAND" field.


47 A3 56BB Rev02 3-21

3.2.3 User Management Function

This is used to manage the data describing the development users' profiles.

This function allows the following actions:

• creation of a user profile (command = CRU)• modification of a user profile (command = MDU)• display of a user profile (command = VIU)• creation of a profile similar to another (command = DUP)• deletion of a user profile (command = DLU)• list of the users and their projects (command = LSU)

The action to be performed is chosen by entering the associated command code in theCOMMAND field of the "USER MANAGEMENT" menu (screen AD03).

With the modification (MDU), display (VIU) and deletion (DLU) commands, it is possible toenter a user name in the screen's PARAMETER field.

3.2.3.1 Creating a User Profile

This function corresponds to the CRU command in the menu.




CREATION OF A USER PROFILE

Name of user : %%%%%%%%%%%%.

Password : %%%%%%%%%%%%.

Default language code : %.

AD30


3-22 47 A3 56BB Rev02

Input of the user's name, password and language code:

• User name: 1 to 12 alphanumeric characters.This name must be unique within a SINDIA 7 TDS.It may be the same as the name of the GCOS 7 catalog but this is not checked.

• Password: 1 to 12 alphanumeric characters.The password is recorded and encrypted in the SINDIA 7 files and never appears inthe displays of the data concerning a user.It may be the same as the name recorded in the GCOS 7 catalog but this is notchecked.

• default language code: 1 numeric characterPossible values 0 = FRENCH

1 = ENGLISH

This default language code will be assigned to the development user if he/she does notindicate the required language code when logging on.



CREATION OF A USER PROFILE

DEFINITION OF PROJECTS AUTHORIZED FOR USER ////////////

Name of principal default project : %%%%%%%%%%%%. Name of secondary default project : %%%%%%%%%%%%.

Names of projects for which the user has access rights to the objects in the projects:

PROJECT RIGHTS PROJECT RIGHTS PROJECT RIGHTS %%%%%%%%%%%%. %. %%%%%%%%%%%%. %. %%%%%%%%%%%%. %. %%%%%%%%%%%%. %. %%%%%%%%%%%%. %. %%%%%%%%%%%%. %. %%%%%%%%%%%%. %. %%%%%%%%%%%%. %. %%%%%%%%%%%%. %. %%%%%%%%%%%%. %. %%%%%%%%%%%%. %. %%%%%%%%%%%%. %. Suite: %. ( RIGHTS : Read = 1 , Read + Write = 2 , No rights = 3 ) AD31

This screen is used to enter all the projects that the user is authorized to work in. Theuser's name is displayed at the top of the screen.

The names of the projects indicated here must correspond to projects declared in theprofiles file using the PROJECT MANAGEMENT transaction. They must be declaredbefore declaration of the development user but the projects do not have to be "active".


47 A3 56BB Rev02 3-23

SINDIA 7 checks that the projects indicated in this screen form exist in the profiles file. Ifthey do not, a message is displayed.

• Default principal project:

- 1 to 12 alphanumeric characters.

- This is the principal working project assigned to the user when he/she logs onif no other principal project is indicated.

- The developer is authorized to access the objects in this project in read/writemode, within the limits of his/her profile.

• Default secondary project:

- 1 to 12 alphanumeric characters.

- This is the secondary working project assigned to the developer when he/shelogs on if no secondary project is indicated.

- The developer is only authorized to read the objects in this project. He/shecannot therefore create, modify or delete objects in the secondary project.

List of authorized projects:

• Table of 12 occurrences of a group of two fields for indicating the projects for which thedeveloper possesses access rights to the objects within them, with an indication of thetype of rights for each project:

- Project name: 1 to 12 alphanumeric characters

- Rights : 1 alphabetic character: value 1 = read only value 2 = read/write- value 3 = no rights.

• The value "3" can be used to prohibit access to the objects in a project by a user whileenabling the user to remain known to the project.

• The user can therefore declare one of these projects in his/her working environment,either when he/she logs on or while working, at the beginning of a transaction, byentering the specific command "MDCTX" in the screen's command field.

• A project can only be declared as a principal project if the user has read/write rights forthe project (2). If this is not the case, the user will be informed by an error message andaccess to this project will be refused.

• You can chain onto the same screen to continue entering further project names bytyping the "+" character in the "Continue" field.

• The maximum number of projects authorized for a developer is 32.


*** SCREEN: AD32 COMMAND %%%%%%%% PARAMETER %%%%%%%%%%%%%%%%%%%%%%%%


3-24 47 A3 56BB Rev02

REMARK ////////////////////////////////////////////////////////////-------------------------------------------------------------------------------- CREATION OF PROFILE FOR THE USER ////////////

Name of associated project : //////////// --------------------------------------------------------------------------- * Transaction * Actions possible on transaction objects * * SINDIA7 * CREAT. * MODIF. * CONSULT. * DELETE. * DUPLIC. * LIST * --------------------------------------------------------------------------- * GESDIC * .%. * .%. * .%. * .%. * .%. * .%. * * GESGRI * .%. * .%. * .%. * .%. * .%. * ./. * * GESTRX * .%. * .%. * .%. * .%. * .%. * ./. * * GESMES * .%. * .%. * .%. * .%. * ./. * ./. * * MESGID * .%. * .%. * .%. * .%. * ./. * ./. * * SIMU * .%. * .%. * .%. * .%. * ./. * ./. * * GESPRG * .%. * .%. * .%. * .%. * .%. * ./. * --------------------------------------------------------------------------- - List of application screens ("LISGRI" Transaction) : ----> %. - List of application messages ("LISMES" Transaction) : ----> %. - Submission of Batch jobs ("BATCH" Transaction) : ----> %. - Projects-user Management ("GESADM" Transaction) : ----> %. - Change of password by the user : -------------------------> %. AD32

This involves describing the development user's profile regarding the various SINDIA 7tool transactions.

A description must be entered for each of the projects declared in the list of authorizedprojects in step 2.

A developer authorized to work under projects P1 or P2 as principal project (read/writeauthorization) may have different profiles for project P1 and project P2.

The sequence chaining steps 3, 4 and 5 is therefore repeated for each of the projectsdeclared in step 2.

This sequence can be interrupted at step 3 by entering the command RTN (return). If so,you return to the user management screen (AD03) and any profiles already input areretained.

• A default profile is proposed to the administrator when the screen form is displayed. Ithas the following characteristics:

• all the transactions are authorized except for the GESADM transaction,

• within each authorized transaction, all the actions are authorized,

• the parameter values for the default characteristics used in the GESGRI transaction arethose defined at the level of the user's associated project.

For the authorized projects declared in step 2, when no profile was defined explicitly byassociating the development user with the project (example: processing aborted by "RTN"command), a default profile prohibiting access to all the transactions is assigned to thedevelopment user for this project.


47 A3 56BB Rev02 3-25

The following data must be entered:

• name of associated project:

- 1 to 12 alphanumeric characters,- The project indicated must figure in the list of authorized projects declared in

step 2.

• truth table of actions authorized in each transaction:

This involves defining the actions that the developer is authorized to use under thisproject, for each of the SINDIA 7 tool transactions.

This is done by entering values in a truth table, as follows:

0 (number),N = action prohibited1,O (letter),Y = action authorized

Use of the transaction can be prohibited by entering 0 (number) or N for all the actionspossible in the transaction.

Transactions containing a single type of action are defined outside the truth table, usingthe values indicated above. This applies to the following:

• list of the application screen forms,• list of the messages,• submission of batch jobs• management of Projects and Users,• modification of the password.


*** SCREEN: AD33 COMMAND %%%%%%%% PARAMETER %%%%%%%%%%%%%%%%%%%%%%%% REMARK ////////////////////////////////////////////////////////////-------------------------------------------------------------------------------- CREATION OF RIGHTS GRANTED TO THE USER //////////// FOR ADMINISTRATIVE MANAGEMENT OF PROFILES (GESADM)

NAME OF ASSOCIATED PROJECT : ////////////

PROJECT MANAGEMENT : Creation of a Project --------------------------------> %. Modification of a Project ----------------------------> %. Display of a Project ---------------------------------> %. List of Users of a Project ---------------------------> %. List of assigned SINDIA7 project codes ---------------> %.

USER PROFILE MANAGEMENT : Creation of a User Profile ---------------------------> %. Modification of a User Profile -----------------------> %. Display of a User Profile ----------------------------> %. Creation of a User Profile by duplication ------------> %. Deletion of a User Profile ---------------------------> %. List of Users and authorized Projects ----------------> %.

(Letter "O",1,Y = ACTION AUTHORIZED - Number "0",N = ACTION PROHIBITED) AD33

This step is only presented to the administrator if the transaction for management ofprojects and users (GESADM) was authorized in step 3.

It can be used to define a list of the actions that a user can use in the GESADMtransaction if he/she has been granted access rights to it.


3-26 47 A3 56BB Rev02

The default option grants the authorized user access to all the actions in the GESADMtransaction.

This step can be used to limit these rights:

• in terms of the actions concerning projects,• in terms of the actions concerning development users.

For each action, the following values are possible:

0 (number),N = action prohibited1,O (letter),Y = action authorized


*** SCREEN: AD34 COMMAND %%%%%%%%. PARAMETER %%%%%%%%%%%%%%%%%%%%%%%%. REMARK ////////////////////////////////////////////////////////////-------------------------------------------------------------------------------- CREATION OF VALUES OF THE DEFAULT CHARACTERISTICS FOR THE GENERATION OF THE SCREEN FORMS FOR THE USER //////////// OF THE PROJECT ////////////

- WORK MODE USED IN THE GESGRI TRANSACTION ............................. %. (GLOBAL MODE = 1 , DETAIL MODE = 2) - TYPES OF TERMINALS GENERATED : - VIP 7760 .. %. - DKU 71XX-72XX .... %. - VIP 78XX .. %. - MINITEL .......... %. - IBM 3270 .. %. - PC7800 EMULATION . %. - DEFINITION CHARACTERS : - VARIABLE FIELD ............... %. - FIXED ADDRESSABLE FIELD ...... %. - LINE REPETITION .............. %. - DEFAULT ATTRIBUTES : - PRINTABLE .................... %. OF VARIABLE FIELDS - MANDATORY .................... %. - RIGHT ALIGN................... %. - ALPHA,EXTENDED NUM.,NUMERIC .. %. (*) - COMPLETED IN FULL ............ %. - USE OF FUNCTION KEYS ........................%. (*)Note - FORMS "RECEIVE SPACE" OPTION ............... %. 0 = alpha - FORMS "DECIMAL POINT IS COMMA" OPTION ...... %. 1 = extended num. - CURRENCY SIGN .............................. %. 2 = pure numeric - PREFIX OF SYMBOLIC NAMES .................. %%%%. AD34

This is used to define the parameter values for the default characteristics used in theGESGRI application screen definition transaction.

The values defined at this level are those automatically assigned to the profile of thedeveloper connected under this project.

The developer can define other values in the GESGRI transaction itself.

The following data is handled by this step:

• working mode in the GESGRI transaction

1 = global mode2 = detailed mode


47 A3 56BB Rev02 3-27

• the types of terminals generated

0 = no object generated for this type of terminal1 = the object will be generated for this type of terminal

• the field definition characters

any character can be used to define a field as long as the character is not usedelsewhere in the screen design (e.g. text of a label).

• the default attributes of the variable fields

Printable

0 = the field is not printable1 = the field is printable

Mandatory

0 = input optional1 = input mandatory

Right alignment

0 = input without right alignment1 = input with right alignment

Numeric, Extended Numeric, Alpha

0 = alphanumeric1 = extended numeric (0 to 9 and + - , . $)2 = pure numeric (0 to 9 only)

Completed in full

0 = not completed in full1 = completed in full

Use of the function keys

0 = no use of the function keys1 = use of the function keys

Currency symbol

Indicate the currency symbol required.This symbol must be one of those accepted by FORMS.

FORMS RECEIVE SPACE option and DECIMAL POINT

0 = the option is not validated1 = the option is validated


3-28 47 A3 56BB Rev02

Prefix of the symbolic names

Optional 4-character alphanumeric fieldUsed to indicate the prefix of the symbolic names for generation ofthe working image of the screen form.

When the screen is first displayed at the beginning of the exchange, it is filled in with thevalues of the corresponding parameters defined at the level of the project.

3.2.3.2 Modification of a User Profile

This function corresponds to the MDU command in the User Profile Management menu.

It is used to modify the general data in a user's profile and the data in the profile for agiven project to which the user is attached.




MODIFICATION OF A USER PROFILE

NAME OF USER : %%%%%%%%%%%%. NAME OF ASSOCIATED PROJECT : %%%%%%%%%%%%.

Use "1" to select the modification required. (Multiple choice authorized)

GENERAL USER PROFILE DATA : 1: User's password ................................................... %. 2: Default projects and language code ................................ %. 3: Projects and rights concerning objects............................. %.

SPECIFIC DATA CONCERNING THE USER LINKED WITH ASSOCIATED PROJECT: 4: Transactions authorized for the user in this Project .............. %. 5: Actions authorized in the "GESADM" transaction for this project.... %. 6: Values of the default characteristics for this project............. %.

AD35

This is a sub-menu for choosing the modification operations, provided to make thefunction more flexible and ergonomic.

The administrator indicates:

• the name of the user to be modified,

• the name of the associated project

This data is optional. It must be entered if the values to be modified concern the profiledata for the user under the project indicated.


47 A3 56BB Rev02 3-29

• the type of modification required:

0 (number) or space = option not selected1 = option selected

Multiple choices are possible and only the steps corresponding to the types ofmodification selected will be presented to the administrator.



MODIFICATION OF USER PASSWORD

Name of User : ////////////

********************************************** * * * NEW PASSWORD : %%%%%%%%%%%%. * * * **********************************************

AD36

Used to change a developer's password.

Enter the new password (1 to 12 alphanumeric characters).

The program checks that the new password is different from the one recorded previously.If they are identical, a message is displayed in the screen's REMARK field and the

modification is refused.This step is followed by a step requesting confirmation of the password.


3-30 47 A3 56BB Rev02



MODIFICATION OF USER PASSWORD

Name of User : ////////////

********************************************** * * * CONFIRM YOUR NEW PASSWORD * * BY TYPING IT A SECOND TIME * * * * %%%%%%%%%%%%. * * * **********************************************

AD37

Asks the administrator to confirm the password by retyping it.

The value entered in step 2 is compared to the value entered in step 3. If they aredifferent, the modification is refused and an error message is displayed.

Step 4 (screen AD3A)

*** SCREEN: AD3A COMMAND %%%%%%%% PARAMETER %%%%%%%%%%%%%%%%%%%%%%%% REMARK ////////////////////////////////////////////////////////////--------------------------------------------------------------------------------

MODIFICATION OF USER PROFILE ////////////

NAME OF DEFAULT PRINCIPAL PROJECT : %%%%%%%%%%%%.

NAME OF DEFAULT SECONDARY PROJECT : %%%%%%%%%%%%.

DEFAULT LANGUAGE CODE : %.

AD3A

This can be used to modify the general data in the user profile. The following data isinvolved:

• the default principal project,• the default secondary project,• the default language code,


47 A3 56BB Rev02 3-31


This step can be used to:

• authorize new projects with indication of the access rights (addition)• prohibit projects previously authorized (withdrawal),• modify the rights granted for existing projects,• remove projects from the list of authorized projects.

The data to be entered is the same as that described in step 2 of the creation phase:

• Table of 12 occurrences of a group of two fields containing:

- Project name: 1 to 12 alphanumeric characters

- Rights : 1 alphabetic character:- value 1 = read only- value 2 = read/write- value 3 = no rights- value 4 = suppression of the project for this user

The values 3 and 4 have the same effect. They correspond to prohibition of the project,but the value 4 also deletes the user-project link, while the value 3 leaves it intact.

In this step, it is possible to add or withdraw projects during the same operation, as longas the following rule is respected:

Existing projects + Projects added - Projects withdrawn must be less than orequal to 32.

The processing and checks performed on the data input during this step remain identicalto the principles defined in step 2 of the creation phase.

You can display the same screen again to continue declaring other projects to be addedor removed by typing the "+" character in the "Continue" field.


3-32 47 A3 56BB Rev02


*** SCREEN: AD32 COMMAND %%%%%%%% PARAMETER %%%%%%%%%%%%%%%%%%%%%%%% REMARK ////////////////////////////////////////////////////////////-------------------------------------------------------------------------------- CREATION OF PROFILE FOR THE USER ////////////


This can be used to modify the data in a developer's profile concerning a given associatedproject.

This optional step is presented to the user in the following cases:

• when an explicit request is entered in the menu displayed in step 1 (screen AD35).• if authorized projects are added in step 5 (screen AD38).

The data to be entered, the checks performed on the values and the rule governingassignment of the default values follow the principles defined in step 3 of the creationphase.

When several projects have been added to the list of authorized projects, the sequence ofsteps 6, 7 and 8 of this phase is repeated for each project added.

This sequence can be interrupted at step 6 by entering the command RTN.


47 A3 56BB Rev02 3-33







This is only presented to the administrator in the following cases:

• if it is explicitly requested in the menu displayed in step 1,• if the GESADM transaction is authorized in step 6.

It can be used to modify the actions which the developer is authorized to used in theGESADM transaction.

The data entered, the checks and the processing performed are the same as in step 4 ofthe creation phase.


3-34 47 A3 56BB Rev02




This is only presented to the administrator in the following cases:

- if it is explicitly requested in the menu displayed in step 1,

- if at least one project was added to the authorized projects in step 5.

It can be used to modify the parameter values of the default characteristics used in theGESGRI transaction.The values authorized and the checks performed are the same as in step 5 of the creationphase.

3.2.3.3 Display of a User Profile

This function corresponds to the VIU command in the user management menu.

It can be used to display the general data concerning a developer and the data in his/herprofile for a given project.



47 A3 56BB Rev02 3-35


*** SCREEN: AD42 COMMAND %%%%%%%% PARAMETER %%%%%%%%%%%%%%%%%%%%%%%% REMARK ////////////////////////////////////////////////////////////-------------------------------------------------------------------------------- DISPLAY OF A USER PROFILE

NAME OF USER : %%%%%%%%%%%%.

Default principal project : //////////// Default secondary project : //////////// Default language code : /

List of projects and access rights on objects in these projects for this user:

PROJECT RIGHTS PROJECT RIGHTS PROJECT RIGHTS //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / CONTINUE -----> %. To view the profile data of this user for a project in the list, enter the project name: %%%%%%%%%%%%. AD42

Display of the general data concerning the user, except for his/her password:

• default principal and secondary projects,• default language code• the list of projects authorized for this user with indication of the type of access

rights.

You can display the rest of the project names in the list by entering "+" in the "Continue"field.

To display the profile data for a given project, provided in steps 2, 3 and 4, the user canenter a project name in the corresponding field.If this information is not entered, the display is limited to step 1.


3-36 47 A3 56BB Rev02


*** SCREEN: AD32 COMMAND %%%%%%%% PARAMETER %%%%%%%%%%%%%%%%%%%%%%%% REMARK ////////////////////////////////////////////////////////////-------------------------------------------------------------------------------- CREATION OF PROFILE FOR THE USER ////////////


Display of the transactions authorized and the actions authorized within the transactionsfor the developer and project indicated.







Display of the actions authorized in the GESADM transaction.This step is not executed if the developer is not authorized to use this transaction.


47 A3 56BB Rev02 3-37




Display of the values assigned to the default characteristics used in the screen formmanagement transaction.

3.2.3.4 Creation of a User Profile Similar to Another

This function corresponds to the DUP command in the user management menu.

It can be used to create a user and attach him/her to a project, taking as a basis anotheruser known to a project.

The associated project of the user to be created does not have to be the same as thereference user's associated project.

This creation involves the simple duplication of the existing user's profile.


3-38 47 A3 56BB Rev02


*** SCREEN: AD41 COMMAND %%%%%%%% PARAMETER %%%%%%%%%%%%%%%%%%%%%%%% REMARK ////////////////////////////////////////////////////////////-------------------------------------------------------------------------------- CREATION OF A USER WITH A SIMILAR PROFILE TO AN EXISTING USER

Data concerning the user to be created :

- Name of user : %%%%%%%%%%%%. - Password : %%%%%%%%%%%%. - Associated project : %%%%%%%%%%%%.

Data concerning similar user :

- Name of user : %%%%%%%%%%%%. - Associated project : %%%%%%%%%%%%.

AD41

Mandatory input of the data concerning the user to be created:

• name of the user• password• name of the associated project

This data is all mandatory.

Mandatory input of the data concerning the reference user:

• name of the user• associated project

3.2.3.5 Deletion of a User Profile

This function corresponds to the DLU command in the user management menu.

This function can be used to delete a user from the profiles file. It causes deletion of allthe user-project links between this user and projects to which he/she is known.



47 A3 56BB Rev02 3-39


*** SCREEN: AD50 COMMAND %%%%%%%% PARAMETER %%%%%%%%%%%%%%%%%%%%%%%% REMARK ////////////////////////////////////////////////////////////-------------------------------------------------------------------------------- DELETION OF A USER PROFILE (Verification of profile before deletion)

NAME OF USER : %%%%%%%%%%%%.


PROJECT RIGHTS PROJECT RIGHTS PROJECT RIGHTS //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / //////////// / AD50

Input of the name of the user to be deleted.

This step is not displayed if the administrator accesses this function using the DLUcommand with a user name in the parameter field of the menu screen.



NAME OF USER : %%%%%%%%%%%%.



Display of the projects to which this user is known.


3-40 47 A3 56BB Rev02



NAME OF USER : %%%%%%%%%%%%.



Confirmation of the deletion by the VAL command.

3.2.3.6 List of Users

This function corresponds to the LSU command in the user management menu. It can beused to display a list of the users with indication of their default principal and secondaryprojects.

The list can be limited to a search interval.

This function involves the following steps:


47 A3 56BB Rev02 3-41



LIST OF USERS

Identifier of first user in list : %%%%%%%%%%%%.

Identifier of last user in list : %%%%%%%%%%%%.

AD39

Input of the identifiers defining the beginning and the end of the list (search interval).

Here, the administrator indicates a user name.

If the identifier defining the beginning of the list is a space, the list begins at the beginningof the file and ends with the identifier defining the end of the list.

If the identifier defining the end of the list is a space, the list ends at the end of the file.


*** SCREEN: AD40 COMMAND %%%%%%%% PARAMETER %%%%%%%%%%%%%%%%%%%%%%%% REMARK ////////////////////////////////////////////////////////////-------------------------------------------------------------------------------- LIST OF USERS

Row. USER NAME DEFAULT PRINCIPAL DEFAULT SECONDARY no. PROJECT PROJECT

// //////////// //////////// //////////// // //////////// //////////// //////////// // //////////// //////////// //////////// // //////////// //////////// //////////// // //////////// //////////// //////////// // //////////// //////////// //////////// // //////////// //////////// //////////// // //////////// //////////// //////////// // //////////// //////////// //////////// // //////////// //////////// //////////// // //////////// //////////// //////////// // //////////// //////////// ////////////

AD40


3-42 47 A3 56BB Rev02

Display of the list containing:

• a rank number• the name of the user• the default principal project• the default secondary project

47 A3 56BB Rev02 4-1

4. The Data Dictionary

4.1 PRESENTATION

The quality of a data processing application and of its realization, as well as the timegained at the development and maintenance levels, are all conditioned by theimplementation of:

• A methodology for analysis and programming,• Tools for structuring and accessing the data manipulated.

With SINDIA 7, the programmer-analyst can take advantage of the facilities offered onseveral levels by the SINDIA 7 nucleus, such as:

• An organic analysis method,• Direct handling of most TDS functions,• Help documentation and tools.

The DATA DICTIONARY is a tool designed to provide extensive help in developing andmaintaining applications with SINDIA 7.

It is an essential tool for setting up links between the various active components inapplication development, and it also makes it unnecessary to redefine data.

The following information is stored in the SINDIA 7 dictionary:

• The description of the programs' working data ,• The descriptions of the screen form data,• The descriptions of the specific data of the SINDIA 7 objects:

- Transactions- Programs- Files- Data Structures.- Entries.- Screen forms- Messages- Copies- Commands- Scenarios


4-2 47 A3 56BB Rev02

- ORACLE table and base names- IDS II Areas- IDS II records

This can be used to obtain an overall view of the SINDIA 7 objects used for eachtransaction, and the CROSS-REFERENCES between the SINDIA 7 objects and theelements in the dictionary.

4.2 DICTIONARY FACILITIES

Because of the facilities which it offers, the SINDIA 7 dictionary improves the efficiency ofdata processing application development and maintenance.

4.2.1 Realization Assistance

The dictionary is enhanced interactively with the description of the working data andstructures.

Deferred batch processing routines are used for automatic generation of the structuresbuilt up during development, as well as printouts of all the objects inside SINDIA 7.

Moreover, dictionary enhancement leads the programmer-analyst to follow a workingmethodology, which is a factor for quality in application development, as well as facilitatingdebugging.

4.2.2 User Assistance

Interactivity makes it easier to use the dictionary, particularly as a result of the permanentavalability of the rules for its use in the help menus (SVP texts).

4.2.3 Maintenance Assistance

This is obtained by means of a printout of the SINDIA 7 internal objects, enabling "impactanalysis", thereby eliminating the need for lengthy searching and greatly facilitating themaintenance process.

The Data Dictionary

47 A3 56BB Rev02 4-3

4.3 BASIC PRINCIPLES OF THE DICTIONARY

4.3.1 The Content of the Dictionary

The internal SINDIA 7 dictionary is made up of two types of entity:

• working and screen data,• the specific data of the SINDIA 7 objects.

4.3.1.1 The working and screen data

These are independent entities, free of any links at first, and involving:

• the entries defined by a name, a label and a format,

• the structures, defined by a name and a label, made up of a set of entries. A structurewill cause generation of a "COPY COBOL" member after implementation of a batchprgram.

4.3.1.2 The specific data of the SINDIA 7 objects

These are mainly relational entities enabling links to be set up between transactions,programs, files, screen forms, messages, COPY COBOL, free commands and helpscreens.

4.3.2 How the dictionary works

4.3.2.1 The specific data of the SINDIA 7 objects

During implementation of the following transactions:

• GESTRX (management of user screen forms),

• GESPRG (batch program management),

• SIMU (management of user transaction scenarios).


4-4 47 A3 56BB Rev02

There is creation or updating of the records in the dictionary file (SINDIC1 et SINDIC2)concerning:

• the transaction• the programs• the user screen forms• the help screen forms (user SVP screens)• the messages• the COPY COBOL members• the free commands• the IDS II areas and records• the ORACLE tables and bases

The various links between these entities are also created in the dictionary.

This how, in the GESTRX transaction (creation, modification or deletion), SINDIA 7generates all the information concerning the transaction in question, the programs, thefiles, the screen forms, the COPY COBOLs, the messages and the free orders.

In the SIMU scenario management transaction, SINDIA 7 manages the data concerningthe various transaction scenarios.

As the internal SINDIA 7 dictionary is itself interactive, the programmer-analyst can alwaysobtain an overall view of the transaction, the different objects making it up, and the linksbetween these objects for all the transactions, through the cross references.

4.3.2.2 The working and screen data

SINDIA 7's GESDIC transaction can be used to obtain a description of the entries. Theseentries concern the working data (working and transaction-storage areas) used by theprograms, and the working data (fields) used in the screens.

Using the entries defined in this way, it is possible to define working structures which willin fact constiture records (files, working and transaction-storage).

The information concerning the entries and working structures is also stored int thedictionary file.

To ensure compatibility with previous releases of SINDIA 7, there is a batch processingroutine for generating a COPY member for each structure defined.

So, when defining the working- and transaction-storage int the GESTRX transaction, thename of the COPY member linked to the working structure defined must be indicated.

However, it will be possible to use the old system by defining the COPYs to be createdduring the working and transaction-storage definition phase.

The Data Dictionary

47 A3 56BB Rev02 4-5

4.3.2.3 Entry-structure cross references

The specific GESDIC transaction in SINDIA 7 is used for defining the data concerning theentries and the working structures, as well as for managing these entries and structures.

The transaction GESTRX is responsible, among other things, for managing the linksbetween the working structures and the other objects in SINDIA 7.

The dictionary also provides an overall view of the transaction in terms of:

• The objects manipulated and used by SINDIA 7• The working structures• The cross references of the SIINDIA 7 objects and the working structures for all the

transactions• The cross references of the entires and the working structures


4-6 47 A3 56BB Rev02

4.4 MIMIC DIAGRAM OF THE DICTIONARY

1 G E S D IC- know the ca te go rie s- know the w o rk s truc tu re

TD S

D ic tion ary f iles

S IN D ICS IN R U B

2 YS TR C O PB atchp rocess ing

L ib rary

< S IN D > S LLIB

- c re a tion o f cop ie s fo r the w ork s tru c tu re s

The Data Dictionary

47 A3 56BB Rev02 4-7

3 G E S TR X

TD S

Transac tion f iles

D ic tiona ry f iles

4 S IM U S IN D ICU p date fo r transa ctio np rog ram s f iles :- P rog ra m s,- F iles ,- G rid s ,- M essag es,- W ork s truc tu re ,- C op y,- O rd ers .

TD S

Transa c tio n f ile s

D ic tionary f ile s

S IN TTPS IN D IC

U p da te th escen ario fo ra transa ctio n


4-8 47 A3 56BB Rev02

F ile sD ic tionary

C onsu lta tion

- tra nsac tion lis t,- tra nsac tion o v erv iew , (p ro gram s, sc re ens , m essag es, cop y, o rde r)- c ross-re fe re nces

G E S D IC

TD S

F ilesd ictio nary

S IN D ICS IN R U B

6 YLIS R E FD efered b a tchp ro cess ing

P ap er ou tp u t fo rim p act a na lyse- l ist o f d ictio nary o b jec t- c ross-re fe ren ce

The Data Dictionary

47 A3 56BB Rev02 4-9

4.5 USING THE DICTIONARY

4.5.1 Creation of the Dictionary

Initially, the files specific to the dictionary (SINDIC et SINRUB) are made up empty whenthe product is delivered.

It is therefore up to the developer to enhance the dictionary with:

• The working data• The screen form data

IMPORTANT

CREATION OF THE ENTRIES AND WORKING STRUCTURES IS AFUNDAMENTAL PRELIMINARY PHASE WHICH MUST BEPERFORMED BEFORE ANY APPLICATION DEVELOPMENTTAKES PLACE.

This phase for creating the entries and working structures is performed using the GESDICtransaction (see the paragraph on the GESDIC transaction).

The developer is not responsible for enhancing the dictionary with the specific data of theSINDIA 7 objects (cross references and relations between objects).

This is done automatically when the various functionalities of SINDIA 7 are implemented.

4.5.2 SINDIA 7 Transactionsmaking use of the Dictionary

Various SINDIA 7 transactions make use of the dictionary,

• either to enhance it and/or update it,• or to gather informatin in it for use by the transaction itself.

The following transactions are involved:

• GESDIC

• GESTRX

• GESGRI

4.5.2.1 GESDIC

This is the basic dictionary management transaction, used for:


4-10 47 A3 56BB Rev02

• working structure management• list of transactions• display of the whole of a transaction• list of the objects in the dictionary

The different functionalities of this transaction are described at greater length in a specificparagraph.

4.5.2.2 GESTRX

This is the transaction for managing (creating, modifying or deleting) the usertransactions.

Each time the developer creates, modifies, duplicates or deletes a transaction, thedictionary is automatically and immediately enhanced and/or updated with all the specificdata of the SINDIA 7 objects involved in the transaction concerned (programs, screenforms, copy messages, etc.).

4.5.2.3 GESGRI

Here, the dictionary is used at two levels:

• Definition of the symbolic names• Updating of specific SINDIA 7 data

Definition of Symbolic Names

When creating and modifying screen forms, the developer retains the possiblity of usingsymbolic names which are different from those generated automatically by SINDIA 7 inorder to describe the screen form fields.

One of the main advantages of the dictionary consists of using pre-defined entrieds in thedictionary as the field names.

If such is the case, it is the image of the entry, with its characteristics as they are difined inthe dictionary, which will be applied to the field.

In the same way, every time a symbolic name is used other than that assigned by SINDIA7 to a screen form field, its presence in the dictionary is checked. If it exists, the image ofthe entry as defined in the dictionary is applied to the field.

The Data Dictionary

47 A3 56BB Rev02 4-11

Note: The fact that a symbolic field name refers to a non-existent dictionary entrydoes not mean that it is created. It is not currently possible to create entriesdirectly using the GESGRI transaction.

As indicated above, the entries and working structures must be created beforeany application development takes place.

Updating the specific data

Whenever a screen form is created, modified or deleted, SINDIA 7 automatically andimmediately updates the specific data in the dictionary.

In the same way, whenever a symbolic field name referring to a dictionary entry ismodified, the specific data in the GESRI dictionary is updated accordingly, if necessary.

4.5.2.4 GESPRG

The structures created in the dictionary and used in a batch program are referenced in thedictionary.

As with the GESTRX transaction, whenever the GESPRG transaction is used formodification, creation or deletion of a batch program, the specific data in the dictionary isupdated accordingly.

4.5.2.5 SIMU

This transaction is used for modelling by creating simulation scenarios for the usertransaction.

These scenarios are referenced in the dictionary.

Every time a scenario is created, modified or deleted, the corresponding specific scenariodata for this transaction is updated automatically and immediately.


4-12 47 A3 56BB Rev02

4.5.3 Mimic Diagram of the SINDIA 7 Transactions using the Dictionary

GESTRX

TDS

SINTTPSINDIC1

SINRUBSINDIC2

D ic tiona ry F ile s

M an ag em ent o f the b a tchp ro gra m g en era tor:- u pd ate o f the in te rn a l d a ta sp ec if ic to S ind ia7 fo r a ll ob jec ts co ncerned in th e p ro gra m .

D ic tionary f iles

M anag em e nt o f user sc ree ns

- de fin ition o f sym bo lic nam es and th e ir im a g e b ased a f ie ld re fe ren ce d in the d ic tion ary

- up da te o f in te rna l da ta sp e cif ic to S ind ia 7 fo r a ll ob jec t concerne d in the screen .

G E S G R I

The Data Dictionary

47 A3 56BB Rev02 4-13

G E S P R G

TD S

S IN P R G B S IN D IC 1S IN D IC 2

S IN R U B

D ic tiona ry f iles

S IM U

TD S

S IN TTP S IN D IC 1S IN D IC 2

M a nag em en t o f th e ba tchp rog ram ge nera tor

- up date o f in te rna l da ta sp ec if ic to S ind ia7 fo r a ll ob jec t concerne d in the p rog ram

M an ag em ent o f transac tionscenarios

- re fe rence a t d ic tion ary lev e l b y scenario s p resen t in tra nsac tion .

- u p date o f in te rn a l da ta sp ec if ic to S in d ia7 fo r a ll o b jec ts co ncerned in th e tra nsac tion .


4-14 47 A3 56BB Rev02

4.6 THE GESDIC TRANSACTION

This the transaction for managing the objects in the dictionary. It is used for the followingoperations:

• Management of the program data (entries):

- creation- modification- consultation- deletion

• Management of the working structures:

- creation- modification- consultation- deletion

• Listing the transactions in the dictionary.

• Viewing the whole of a given transaction:

- programs- files- working structures- screen forms- messages- copy COBOL- list of user commands- list of existing scenarios

• Listing the references of the objects in the dictionary:

- references of a program- references of a file- references of a working structure- references of a screen form- references of a message- references of a copy- references of a command- references of an entry- references of an ORACLE base- references of an ORACLE table- references of an IDS II diagram- references of an IDS II area- references of an IDS II record

4.6.1 Implementation of the GESDIC Transaction

The GESDIC transaction is implemented in the same way as the other SINDIA 7transactions, by entering "GESDIC" in the screen's COMMAND field and pressingTRANSMIT.

The Data Dictionary

47 A3 56BB Rev02 4-15

This action causes display of the general dictionary menu screen form:

ORDER %%%%%%%%. PARAMETER %%%%%%%%%%%%%%%%%%%%%%%%. REMARK--////////////--////////////----------------------------------------------------

DICTIONARY MANAGEMENT

1 - Description of program data (entries).

2 - Description of Work Structures.

3 - Global display of a transaction.

4 - References of dictionary objects.

5 - List of Transactions.

6 - List of entries.

7 - List of Structures.

Operator Choice: % Project Origin: %

The programmer enters a code corresponding to the required function in the orperatorchoice field and presses TRANSMIT.

Note: As for the other SINDIA 7 transactions, there are help texts linked to theGESDIC transaction, consultable at any time by means of the command SVP.


4-16 47 A3 56BB Rev02

4.6.2 Description of the Program Data (Entries)

This function of GESDIC is obtained by entering the code 1 in the operator choice field onthe transactions's "menu" screen form. The entry management screen form is thendisplayed.


PROGRAM DATA MANAGEMENT

- Enter one of the following orders into the ORDER zone:

C --> Creation of an Entry.

M --> Modification of an Entry.

I --> Innquiry of an Entry.

S --> Deletion of an Entry.

D --> Copy of an Entry.

- Enter the Project Origin --------------> .%.

For the M, I and S orders enter an entry code into the PARAMETER zone.

Except when the command is C (entry creation), the operator simply enters an entry namein the parameter field, whether the command is M (modification), I (consultation) or S(deletion).

The Data Dictionary

47 A3 56BB Rev02 4-17

4.6.2.1 Creating an entry (C Command)

Entry creation is the essential phase prior to any transaction development. It enables thedictionary to be enhanced with the new entries used during development.

Entry creation is performed using the screen form below.

ORDER %%%%%%%%. PARAMETER %%%%%%%%%%%.%%%%%%%%%%%%%. REMARK--////////////--////////////----------------------------------------------------

CREATION OF AN ENTRY

Name of the Entry .%%%%%%%%%%%%.

Alias of the Entry .%%%%%%%%%%%%.

LABEL FORMAT

Input Internal

.%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%. .%%%%%%%%%%%%%%%. .%%%%%%%%%%%%%%%.

If the programmer wishes to create an entry from an existing entry, the name of this entryis input in the ALIAS field, so there is no point in filling in the label and the format.

Any entry created from another constitutes an entry ALIAS.

The link thus constituted is entered, and the alias entry takes on the characteristics (labeland format) of the entry of which it is the ALIAS.

When the entry to be created is not the ALIAS of another entry, input of the label and theinternal format is mandatory.

The format of the entry may be:

• An optional input format, except for entries used as symbolic names in screen formfield definition,

• An internal format which is mandatory and may contain all the COBOL functions.

Note: There cannot be more than 15 ALIAS entries for a given "mother" entry.


4-18 47 A3 56BB Rev02

4.6.2.2 Modifying an entry (M command)

This is performed using the seen form below:

ORDER %%%%%%%%. • PARAMETER %%%%%%%%%%%%%%%%%%%%%%%%. REMARK--////////////--////////////----------------------------------------------------

MODIFICATION OF AN ENTRY

Name of the Entry .////////////.

Alias of the Entry .%%%%%%%%%%%%.

LABEL FORMAT

Input Internal

.%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%. .%%%%%%%%%%%%%%%. .%%%%%%%%%%%%%%%.

Elementary entry with no ALIASes.

The field "ALIAS of the ENTRY" is filled in if the user wishes to link this entry to another.In this case, the LABEL and FORMAT fields are re-initialized. The newly modified entrywill be an ALIAS.

The entry to be modified is an ALIAS of another entry.

• ALIAS entry:When the screen form is displayed, the field "ALIAS of the ENTRY" contains an entryname: it is fan elementary entry. The user may:

- Re-initialize the field:The link is broken and the entry becomes an elementary entry. The LABEL andFORMAT fields can be modified.

- Input a new entry name.The previous link is broken, and a new link is created with the entry whose namehas been entered. The LABEL and FORMAT fields are re-initailized.

• Elementary entry containing ALIASes:Any entry input in the ALIAS field is rejected. If the user modifies the LABEL andFORMAT fields, all the data concerning the entry's aliases are modified.

The Data Dictionary

47 A3 56BB Rev02 4-19

4.6.2.3 Consulting an entry (I Command)

This is done using the screen form below:


INQUIRY OF AN ENTRY

Name of Entry: .////////////.

LABEL FORMAT

Input Internal

.//////////////////////////////. .///////////////. .///////////////.

LIST OF ALIASES

1 ////////////. 2 ////////////. 3 ////////////. 4 ////////////. 5 ////////////. 6 ////////////. 7 ////////////. 8 ////////////. 9 ////////////. 10 ////////////. 11 ////////////. 12 ////////////. 13 ////////////. 14 ////////////. 15 ////////////.

If an entry has aliases, their names are indicated in the LIST of ALIASes table. Amessage indicates that a new entry can be input in the parameter field.

4.6.2.4 Deleting an entry (S Command)


DELETION OF AN ENTRY

Name of Entry: .////////////.

LABEL FORMAT

Input Internal

.//////////////////////////////. .///////////////. .///////////////.

LIST OF ALIASES

1 ////////////. 2 ////////////. 3 ////////////. 4 ////////////. 5 ////////////. 6 ////////////. 7 ////////////. 8 ////////////. 9 ////////////. 10 ////////////. 11 ////////////. 12 ////////////. 13 ////////////. 14 ////////////. 15 ////////////. DI13D

Deletion is confirmed by entering the command VAL.

The deletion is only effective if:

• The entry ALIASes are deleted• The entry is not defined in a structure• The entry is not defined in a screen form


4-20 47 A3 56BB Rev02

4.6.3 Description of the Working Structures

This GESDIC function is obtained by entering the code 2 in the operator choice field onthe transaction's menu screen form.

The working structure management screen form is then displayed.


MANAGEMENT OF WORK STRUCTURES

- Enter one of the following codes into ORDER zone:

C --> Creation of a work structure.

M --> Modification of a work structure.

I --> Inquiry of a work structure.

S --> Deletion of a work structure.

D --> Copy of a work structure.

- Enter the Project from -------------------> .%.

For the M , I and S orders enter a structure code into the PARAMETER zone.

Except when the command is C (structure creation), the user simply enters a structurename in the parameter field, wheter the command is M (Modification), I (consultation) or S(Deletion).

4.6.3.1 Creating a working structure (C Command)

A working structure is made up of a collection of elementary entries and, if necessary,group entries belonging to the same logical set.

Structure creation therefore consists in formatting this set.

Two types of entries can be used:

• Group entries: these do not figure in the dictionary, and their role is to define a sub-setof elementary entries within the structure.

• Elementary entries (or their ALIASES): which must be defined in the dictionary.

The Data Dictionary

47 A3 56BB Rev02 4-21

Structure creation is performed using the following screen form:

ORDER %%%%%%%%. PARAMETER %%%%%%%%%%%%%%.%%%%%%%%%%. REMARK--////////////--////////////----------------------------------------------------

CREATION OF A WORK STRUCTURE Page: //

Name of the Structure : %%%%%%%%%%%%.

Label : %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%. Redefines 1

Name Label Picture Group Occurs 2 Parameter Value 3 1 %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. 2 %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. 3 %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. 4 %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. 5 %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. 6 %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. 7 %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. 8 %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. 9 %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. 0 %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. Next: %

Example of how to build up a structure

Example of how to build up a structure:

The user wants to create the structure WZONCLI with the following entries, definedbeforehand in the dictionary:

• WNOCLI, WNOM, WPREN, WTEL, WNONUE, WRUE, WCODPOST, WVILLE.

a) Enter the name of the WZONCLI structure and a label in the corresponding fields.

b) Formatting of the entries:A level is assigned to every entry input, whatever its type.The level is not absolute, but constitutes an entry point for copy COBOL generation(see chapter BATCH PROCESSING)

Example input:

1. WCLE (group entry): assign a label and level 1

2. WNOCLI: As with the COBOL method, enter a lower level (2)

3. WZONOM identical to 1

4. WNOM identical to 2

5. WPREN identical to 2

6. VVTEL identical to 2

7. WADRESSE identical to 1, assign level 2

8. WNORUE identical to 2, assign level 3

9. WRUE identical to 8

10. WDEP identical to 7, assign level 3


4-22 47 A3 56BB Rev02

11. WCODPOST identical to 8, assign level 4

12. WVILL identical to 11

If the entry is in the dictionary, the corresponding label and format are displayed in theLABEL and PICTURE fields. They cannot be modified.

After formatting, press the TRANSMIT key and a message is displayed inviting you toconfirm. Enter the command VAL. Actual creation is indicated by a return to the previousmenu.

Note: The number of entries in a structure is limited to 110.

The Data Dictionary

47 A3 56BB Rev02 4-23

4.6.3.2 Modifying a working structurel (M Command)

This is done using the screen form below:

ORDER %%%%%%%%. PARAMETER %%%%%%%%%%%%%%%%%%%%%%%%. REMARK--////////////--////////////---------------------------------------------------- MODIFICATION OF A WORK STRUCTURE PAGE: //

Name of the Structure : ////////////.

Label : %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%. Redefines 1

Name Label Picture Group Occurs 2 Parameter Value 3 %% %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. %% %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. %% %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. %% %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. %% %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. %% %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. %% %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. %% %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. %% %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. %% %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. Next: %

Structure modification involves the entries contained in the structure.

Several types of modification can be performed:

• substitution of one entry for another• addition of one (or more) entries after a given entry• insertion of one (or more) entries before a given entry• deletion of one or more entries

The mechanism for modifying the content of a structure is basically a text editor similar tothe GCOS 7 EDIT command.

The programmer indicates the command to be executed by inputting a letter followed by anumber from 1 to 9 next to the line containing the entry involved.

Command codes

An → Addition of n entries after the specified entry.

In → Insertion of n entries in fornt of the specified entry.

Dn → Deletion of n entires starting with the specified entry.

To substitute one entry with another, simply modify the name of the corresponding entry.


4-24 47 A3 56BB Rev02

4.6.3.3 Consulting a working structure (I Command)

This can be done using the same screen form as that used for creation.

ORDER %%%%%%%%. PARAMETER %%%%%%%%%%%%%%.%%%%%%%%%%. REMARK--////////////--////////////----------------------------------------------------

INQUIRY OF A WORK STRUCTURE Page: //

Name of the Structure : %%%%%%%%%%%%.

Label : %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%. Redefines 1 Name Label Picture Group Occurs 2 Parameter Value 3 1 %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. 2 %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. 3 %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. 4 %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. 5 %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. 6 %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. 7 %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. 8 %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. 9 %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. 0 %%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%%%%%%%%%%%%%%. %%. %. %%%%%%%%%%%%. Next: %

4.6.3.4 Deletion of a working structure (S Command)

A working structure can only be deleted if all its links with specific SINDIA 7 internal datahave been broken.

Consequently, a structure cannot be deleted if it remains defined in a program ortransaction.

Deletion must be confirmed using the VAL command.

Execution of the deletion is indicated by an automatic return to the previous menu.


DELETION OF A WORK STRUCTURE

Name of the structure: ////////////

The Data Dictionary

47 A3 56BB Rev02 4-25

4.6.4 Displaying the Whole of a Transaction

This GESDIC function is obtained by entering the code 3 in the operator choice field onthe GESDIC transaction menu screen.

The programmer-analyst can then view the different components of the transaction(programs, files, screen forms, etc.) using specific screen forms

The elements to be displayed are selected by indicating the transaction name and thecode corresponding to the type of display selected in the operator choice field.


GLOBAL DISPLAY OF A TRANSACTION

List of TPR Programs............. 1 List of Files.................... 2 List of Work Structures ......... 3 List of Screens ................. 4 List of Messages ................ 5 List of Copies ................. 6 List of Orders ................. 7 List of Scenarios ............... 8 List of ORACLE tables ........... 9 List of IDS II areas ............ 10

Name of Transaction : %%%%%%%%

Project Origin : %

Operator Choice : %%

4.6.5 Reference of the Objects in the Dictionary

This GESDIC function is obtained by entering the code 4 in the operator choice field onthe tranaction's menu screen form.

It is used to obtain a list of the cross references of the different objects in the dictionary.

Only one object can be selected at a time.


DICTIONARY OBJECT REFERENCES

Program References : %%%%%%%%. File References : %%%%%%%%%%%%. Work Structure References : %%%%%%%%%%%%. Screen References : %%%%. Message References : %%%%. Copy References : %%%%%%%%%%%%. Order References : %%%. Entry References : %%%%%%%%%%%%.

- Enter one and only one identifier


4-26 47 A3 56BB Rev02

4.7 THE BATCH TOOLS LINKED TO THE DICTIONARY

As well as the GESDIC transaction, used to manage the dictionary as a whole, there arealso two associated batch tools:

• JFSTRCOP• JFLISREF

4.7.1 The JFSTRCOP Procedure

The JFSTRCOP procedure generates a "copy" member of a structure createdinteractively in the corresponding < TDS >.SLLIB.

Activation of the procedure

EJR JFSTRCOP: SLLIB, MEDIA, DVC (structure name, n, 1) where n represents therequired COBOL level from which you wish to generate the "copy" member (a valuebetween 01 and 49) and 1 means that there is no prefix for the entries which constitute it(up to 4 alphanumeric characters are allowed).

4.7.2 The JFLISREFı Procedure

This procedure is used to obtain a printout of the cross references of the different objectsin the dictionary.

It can therefore be used for carrying out impact analysis.

Activation of the procedure

EJR JFLISREF: SLLIB, MEDIA, DVC (parameters).

The following parameters must be supplied:

D List of the entries, structures and transactions

R List of all the references (TPR, Screen forms, commands,Messages, Copies, Structures, entries):

Rl: References of the TPRsR2: References of the Screen FormsR3: References of the CommandsR4: References of the MessagesR5: References of the CopiesR6: References of the StructuresR7: References of the Entries

1 List of all the references plus the entries, structures andtransactions.

47 A3 56BB Rev02 5-1

5. Developing a Transaction Using SINDIA7

5.1 OBJECTIVES

Once the transaction has been analyzed using the SINDIA7 method, you must finalize theman-machine dialog with the end users before beginning the actual programming of thetransaction.

This section describes how, using the SINDIA7 analysis sheet, the programmer analystimplements a mock-up of the man-machine dialog for validation very directly and simplywithout any cost to programming; this enables you to finalize the transaction-based dialog.The next operation consists in generating the transaction skeleton.

You can then program processing operations with certainty as to results. Thisprogramming as well as the description of the skeleton is covered in the next chapterentitled "TPR Encoding".

Below is the script concerning the development of a transaction under SINDIA7. Thisscript has been stripped to basics as it assumes that the programmer analyst is using theon-line SINDIA7 documentation. As far as documentation is concerned, remember that:

a) you can call up the on-line documentation at any time by typing HLP (SVP) in theORDER field, then return to the original context by typing R in the same field.

b) you can consult the full SINDIA7 manual by calling up the SINSVP transaction. Toexit from this transaction, the usual method applies: use the END (F) command inthe ORDER field or activate another transaction.


5-2 47 A3 56BB Rev02

5.2 SCRIPT FOR DEVELOPING A TRANSACTION UNDER SINDIA7

ACTION COMMENTS

1. Launch the SINDIA7 TDS The startup JCL is the JGEXETDS memberof the source library associated withSINDIA7.

2. Log on to the SINDIA7 TDS If, during SINDIA7 installation, you keep thedefault values, when logging on, the LOGONTPR activates the SINSVP transaction (on-line documentation)

3. Consult the documentation To get the SINSVP instructions if necessaryfor use: use the HLP (SVP) command

4. Enhancement of the Data dictionary GESGRI transaction (see Chapter 4).

5. Create the SINDIA7 forms GESGRI transaction The parameters to beused to initiate the dialog are the form name(up to 4 characters) and the name of thefunction chosen: C: Create I: interrogate (for testing) M: Modify S: Delete/Suppress

6. Generate the GCOS7 binary objects as well as the COBOL interface structures

BATCH transaction- Select option No. 3 to submit the JGMAJFOR member of the source library associated with SINDIA7

- Pass the form name as a parameter.

7. Create the messages associated with the exchanges, as well as the error messages

GESMES transactionIn addition to the transaction name, theparameters are CME, IME, MME, SME forcreating, interrogating, modifying anddeleting a message, respectively.

This phase is mandatory for storing themessages in the SINDIA7 file of messages

Developing a Transaction Using SINDIA7

47 A3 56BB Rev02 5-3

ACTION COMMENTS

8. Create the data for the transaction TPRs GESTRX transaction (C function).This transaction uses a dialog for definingALL the data required for simulating,documenting and generating the TPRsmaking up the transaction.

At each stage, you can take advantage ofon-line documentation (HLP-SVP).

This is the transaction used to declare theforms and messages associated with theexchange.

You must pay particular attention whenentering data corresponding to "descriptionof the exchange" of the SINDIA7 analysissheet, as the data is used for the analysis fileset which is generated and appears ascomments in the generated skeleton.

9. Display the data you have just entered using GESTRX (for checking).- Optional -

GESTRX Transaction (I fonction). The sameforms used for creating are displayed andfeature in write-protected mode the valuesentered.

10. If necessary, you can modify the data entered using GESTRX - Optional -

GESTRX transaction (M function). The sameforms used for creating are displayed andfeature the current values which can bemodified.

11. Define the simulation scripts and implement the prototype for validation - OPTIONAL BUT RECOMMENDED

SIMU transaction. You can create up to 10scripts with 256 steps and execute them(step by step or automatically) and modifythem while they run.

12. Depending on the case:

- the scripts can be enhanced (not complete enough)

SIMU transaction.

- or the data entered can be amended: forms GESGRI transaction then launch the

associated Batch job.

messages GESMES transaction.

transaction definition GESTRX transaction M option or in extremecases deletion

(GESTRX S option) before fully rebuildingusing the C option.


5-4 47 A3 56BB Rev02

ACTION COMMENTS

We recommend that you iterate insimulation and implementation phaseuntil fully satisfied. Corrections,additions and modifications are fasterand more efficient to do at this stage.

Note that these simulation scripts havemultiple uses. They can be used:

- as references for specifying a transaction,- for training,- for demonstrations.

13. Log out from the TDS BYE

14. Stop the TDS


47 A3 56BB Rev02 5-5

5.3 GENERATING THE TRANSACTION SKELETON - REGENERATING THETDS

This phase precedes the actual encoding phase. The data which has been entered duringthe previous phase and stored in the SINDIA7 files is used to create the COBOL skeletonof the transaction in which user code is entered to complete it. You must also provide thedata required for (re)generating the TDS in this phase.

The script below assumes that the programmer analyst is logged on to the SINDIA7 TDS.

ACTION COMMENTS

15. Extract in the source library (from theSINDIA7 files) the descriptions of the TPR'sof the transaction

16. Generate the transaction TPR skeletonsin the source library

BATCH transaction.- Select the appropriate option to submit JFEXTTPR job of source library associated to SINDIA7The parameters of JFEXTTPR are:- parameter 1 : the transaction code- parameter 2 : the name of a TPR in the transaction- parameter 3 : a prefix (optional) whose default value is "X".

JFETTPR generates in the source library amember corresponding to the TPR (namegiven by param2) of the transaction (namegiven by param1).

The name of the member is "parameter3""program-id" where "program-id" is the valueof PROGRAM-ID of TPR.

This member contains all data necessary forthe generation of the skeleton of the TPR(step 14).

This operation must be performed for eachTPR of the transaction.

BATCH transaction.- select option No. 7 to submit JFGENTPRjob of source library associated withSINDIA7.Parameters are:- parameter 1 : name of source memberbefore extension- parameter 2 : name of source memberafter extension


5-6 47 A3 56BB Rev02

ACTION COMMENTS

This operation must be performed for eachTPR in the transaction in order to generatethe transaction TPR skeletons in the sourcelibrary. For each TPR, the name to assign inparameter 1 is none other than the nameobtained in step 14.It is advised to use the "program-id" of eachTPR as parameter 2.For obvious reasons, JFGENTPR must notbe run until JFEXTTPR has terminated (forexample, run them in a class with amultiprogramming level equal to 1).

17. Enter the declaration for the newtransaction TDS in SINDIA7. - Optional

MESGID transactionEnter the new transaction code then one ofthe commands (C, I, M, S) accordingly(same meaning as for GESGRI).

This informs SINDIA7 of all the data on the"message clause" which will be used togenerate the TDS.

SINDIA7 does not use this data functionally;this is why it is optional. It can be enteredoutside SINDIA7. The advantage of enteringit using SINDIA7 is that it can be consultedand modified using SINDIA7 tools.

18. Include the new transaction declarationin the TDS generation commands.- Optional

This job is not included in the standardBATCH transaction menu, but can be added.

The job is the JFMAJMSG member of thesource library associated with SINDIA7.

This operation can be done outsideSINDIA7.

The values of the various options to bespecified can be the default ones providedby SINDIA7. For further details, refer to thechapter entitled "Optimizing the GCOS7environment".

19. Regenerate the TDS Run the JFGENTDS job in the source libraryassociated with SINDIA7.

NOTE: The two JFEXTTPR and JFGENTPR stages are no longer necessary in versionN20 of SINDIA7. It is SPECIFICALLY recommended that only the "COPY"clauses be used to insert the procedural (COBOL) part in the various sections ofthe TPR


47 A3 56BB Rev02 5-7

At this point, the user has only to enter his own processing operations in the SINDIA7skeleton, compile and link (job: JFCOMPTR). The transaction is automatically handledwhen the TDS is rerun by the JFEXETDS job.


5-8 47 A3 56BB Rev02

5.4 ADDITIONAL INFORMATION

WHEN READING THIS MANUAL FOR THE FIRST TIME, YOUSHOULD SKIP DIRECTLY TO THE NEXT SECTION.

The information provided below is in addition to the comments pertaining to the abovescripts in order to make it easier to implement them. The same numbering is used.

Action 5: GESGRI

The GESGRI transaction is also used to create a form from a model form.

There are three types of form fields:

• constant fields (drawings, heading text),

• variable fields (the program as well as the terminal operator can write to these fields),

• fixed addressable fields (the program can write to these fields but not the terminaloperator as they are protected).

Two working modes are available:

Global mode

allows definition of several areas in the form at the same time

Detail mode

allows area-by-area definition of the form.

The dialog consists of 6 phases:

• you specify the action involved (creation, modification, etc.).

• you define the screen format: type of terminal, conventions used and default prefix forthe names of variables generated,

• you design the form,

• you define all the variable fields, one by one: symbolic name, field attributes, displayattributes. Content control values, initialization value. Level of reference field for a fieldbelonging to a table.

• you define one by one all the addressable fixed fields: symbolic name, display attribute,initialization value.

• you define the display attributes on all the constant fields (form headings).

When defining the video display, it is possible to enter "?" in the video definition field oftool screen form. This causes a help screen to be displayed, containing the range ofbackground and character display attributes. Selecting a display attribute directly from thishelp screen directly assigns the corresponding value to the user screen form field forwhich the "?" had been keyed.


47 A3 56BB Rev02 5-9

Note: Do not forget to terminate this phase by TRANSMIT. Do not use HLP (SVP) inthis phase.

When defining the video display, attributes are specified directly on the screenusing a character. By default, a video definition is valid to the end of the lineexcept if it is overridden by another definition. "Q" is used to return to normalbrightness.

Note that the JFLISGRI job prints the form designs on paper.

Action 7: GESMES

The message definition includes:

• its number,

• the value of SINEFF

"O" (letter) The attached form is displayed. Display for all data from theprogram is enabled globally. This value, by default global,can be overridden for each individual field (see the nextchapter entitled "TPR Encoding" ).

"N" The attached form is displayed. Display for all data from theprogram is disabled globally. This default value can beoverridden for each individual field.

• parameter setting characterEnter n characters for parameter setting in the text for aparameter of length n.

• message text Only one parameterized field is possible, positionedanywhere in the fixed part of the text.

• cursor position Fields are numbered from left to right and from top to bottomstarting from 0 and taking into account all the fields to besent.

REMARK 1: If (by mistake) you enter a cursor number higherthan the actual number of fields, the cursor will be positionedon the last field.

REMARK 2: If (by mistake) you try to position the cursor on afixed addressable field, the cursor will be positioned on theCOMMAND (ORDER) field (the 1st variable field).

REMARK 3: These two errors may occur together: if youspecify (by mistake) a cursor number higher than the numberof fields and if the last field on the form is a fixed addressablefield, the cursor will be positioned on the COMMAND(ORDER) field.

To obtain a hardcopy of messages, run the JFLISMES job whose parameters are theprintout boundaries (in numbers of messages).

Action 8: GESTRX

This is the user's transaction management tool. It runs under TDS.


5-10 47 A3 56BB Rev02

This tool transaction dialog takes up about fifteen screens, enabling you to define all thedata needed for simulation, documentation and generation of the TPRs making up thetransaction .

It enables the context of each transaction to be defined and broken down into elementarychanges without, nevertheless, taking into account input of the Cobol code specific to theprocessing of the data.

The data entered is stored in file SINTTP. This file will then be used by a batch job(JFEXTTPR) to create the transaction's COBOL skeleton in which the user code will beentered under IOF in order to complete it.

This batch procedure (JFCRETPR) allows an executable program to be generated

G E S T R X

S IN M A Q

S IN D IA 7 to o l scre enform s

TD S

IO

S IN TTP"Tran sa c tion ske le ton " f ile

I

JF C R E TP R

M im ic D iag ra m o f G E ST R X

S LL IB

TP R C OB O L sou rc e m em b er,w h ich c an be ru n a fte rcom p ilin g a nd e d iting (L IN K )

Automatic generation of exchange chaining is integrated when the TPR is generated. Thismeans that a complete documentation is linked to the transaction and there is no need toprogram anything other than the application's specific elements (data, files, specific dataprocessing code).

Furthermore, it should be noted that, in the event of a modification, GESTRX works fromthe SINDIA7 source, updated under IOF and before generation using JFGENTPR: thusretrieving the COBOL code input under IOF.


47 A3 56BB Rev02 5-11

With the addition of the dictionary, you have an exhaustive list of transactions, whichmeans that you can duplicate any existing transaction whose kinematics are similar tothose of the new transaction you want to create.

GESTRX functions

• creation of user transaction

• modification of user transaction

• interrogation of user transaction

• deletion of user transaction

This transaction has a main menu which is called using the GESTRX transaction code inthe COMMAND (ORDER) field.

Before you use it, you should consult the on-line documentation associated with eachform.

Note that one form is used to declare WORKING STORAGE fields (not kept between twoexchanges) and another form to declare TRANSACTION STORAGE fields (kept betweentwo exchanges).

IMPORTANT

An item of data that you wish to pass from one exchange to anothermust be entered in TRANSACTION STORAGE. An item of data whichis only used for the duration of 1 exchange should be declared inWORKING STORAGE.

Without going into the subject matter of the next sections, note that this point isfundamental as far as optimization is concerned.

When you declare fields to be saved between two exchanges (TRANSACTIONSTORAGE), because of TDS architecture, at each exchange these fields will be copied toa specific TDS working space then restored for the next exchange. This is how TDSshares resources such as user codes or process numbers. It is clear that the smaller thetransaction storage, the best for the performance.

THE PRINCIPLE OF AUTOMATIC CODE GENERATION

The purpose of automatic code generation is for the code required for an executabletransaction to be reduced to a minimum by SINDIA7.

The computer expert only programs what is specific to his own application (data, files...).

Automatic code generation consists in managing chains at the GESTRX level, togetherwith a number of SINDIA7 variables:

• SINECH: exchange indicator.

• SECH: indirect exchange indicator.

• SINTRX: field which is given a value in order to change transactions.


5-12 47 A3 56BB Rev02

• SINMASK: name of screen form to be displayed, takes priority over the exchange table.

• SINNUM: number of message to be displayed in the REMARK field.

• SINCUR: position of the cursor in the form to be displayed.

• The authorized commands (orders) in the next exchange to be processed.

47 A3 56BB Rev02 6-1

6. TPR Encoding

The previous section showed how to obtain a transaction skeleton. The description belowexplains the structure of the skeleton and defines the points where user code can beinserted in the skeleton.


6-2 47 A3 56BB Rev02

6.1 DESCRIPTION OF THE SKELETON (AFTER EXTENSION)

PROGRAM-ID. XXXX.

...WORKING-STORAGE SECTION.01 TABTEC . . . . . . . . . . . . . . . . . . . ....

Table of exchanges: contains the names ofthe messages linked to the screen forms.

01 TABORD . . . . . . . . . . . . . . . . . . . ....

Table of commands: contains the authorizedcommand names

01 TABFC . . . . . . . . . . . . . . . . . . . . ....

Table of function keys and correspondingcommands.

01 TABSVP . . . . . . . . . . . . . . . . . . . . Table of help screens per exchange....COPY SINTPRWS . . . . . . . . . . . . . . . Table of TPRs per exchange....COPY SINMESWS . . . . . . . . . . . . . . . Table of TPR messages...COPY SINWR71 . . . . . . . . . . . . . . . . ....COPY SINWS71 . . . . . . . . . . . . . . . . ....

SINDIA7 reserved working variables andworking variables for redefining screenvariables

LINKAGE SECTION......01 TRANSACTION-STORAGE variables kept between two exchanges...PROCEDURE DIVISION . . ....GO PSIN1 PSN2 PSN3 ... PSINx DEPENDING ON SINECH....PSINF . . . . . . . . . . . . . . . . . . . . . ....

Insert the processing code at normal end oftransaction (END command F)

FSINF. . . . . . . . . . . . . . . . . . . . . . ....PSINABT. . . . . . . . . . . . . . . . . . . . ....

Insert the processing code for a cancellation(CAN command ABT)

...FSINABT. . . . . . . . . . . . . . . . . . . . ....PSIN1. . . . . . . . . . . . . . . . . . . . . . . Insert the processing code for exchange 1.... IF chaining condition GO PSIN1-CHAIN1.......

TPR Encoding

47 A3 56BB Rev02 6-3

PSIN1-ENCH1.

MOVE N TO SINECHMOVE SINOK TO SECH.M O V E "tran sac tion nam e " TO S IN TR XMOVE GRxx TO SINMASKM O V E " m e ssa ge n °" TO S IN N U MM O V E "order n°" TO S IN C U R

A utom atic ge neration o fth e cha in m an ag e m e nt co de

FSIN1-ENCH1.......................PSIN1-ENCH2.......................FSIN2-ENCH2.FSIN1.............................................PSINX1.............

If c ha in ing co nd it ion GO PSINX1-ENCH1.

Insert th e user c om m an dp ro c ess ing code

PSINX1-ENCH1.

MOVE N TO SINECHM O V E S IN O K TO S E C H .M O V E "TR X n am e" TO S IN TR XMOVE GRxx TO SINMASKM O V E "m es sag e n°" T O S IN N U MM O V E "orde r n °" TO S IN C U R

A uto m a tic g en era tio n o fthe ch ain m a na gem en t c od e

PSINX1-ENCH1.FSINX1


6-4 47 A3 56BB Rev02

6.2 SINDIA7 STATEMENTS

This section explains how to interface with SINDIA7 when encoding the processingoperations. As a general rule, SINDIA7 variable names begin with "SIN".

6.2.1 Chaining

• To chain an i-level exchange or a command processing exchange to another i-levelexchange, assign the desired exchange number to SINECH:

• To chain two processing operations together (indirect chaining):

Say that the exchange will be indirect (assign SECH)

MOVE SINOK TO SECH

and assign the exchange number

MOVE n to SINECH

• To chain two TPRs together, in principle there is nothing to be done since this isalready known by SINDIA7. If you want to chain to a TPR not developed usingSINDIA7, you assign a value to TDS variable NEXT-TPR

MOVE "TPR-name" TO NEXT-TPR

You must also assign a value to the SINLOP variable (see below).

6.2.2 Receiving Data

• The value of the COMMAND (ORDER) field is received in the SINTRY variable.

Note: It is a good idea to test the value of SINTRY when processing PSINF. If SINTRYis not "END" (F) nor a known transaction name, this means that there is an enduser error which must be handled as such.

• The value of the PARAMETER field is received in the SINPAR variable.

• From a screen form: the value of a field whose name is declared as "FIELD" (forinstance) when the form was created is received into a variable whose name is builtfrom the concatenation of the letter "R", a prefix (noted "pfx"), and the name given tothe field ("FIELD" in this example):

RpfxFIELD

The letter "R" recalls that a receive operation is involved.

The prefix is common to all the field names in the form. In the first form definition form(GESGRI), SINDIA7 proposes a value but does not display it in the later name definitionphases. If you do not want a prefix, you must force it to blank. It is a good idea to use

TPR Encoding

47 A3 56BB Rev02 6-5

some sort of rule on a routine basis, for example, use the form's name as a prefix. Acommon error is to omit the value of the default prefix.

Variable names R... are automatically declared due to the form creation process.

MOVE RpfxFIELD TO ...

6.2.3 Sending Data

(The REMARK field is covered below).

In the simplest case, to display a value in the field of name FIELD, part of a given form,you must assign a value to the variable whose name is built from the concatenation of theletter "E" ("E" for Emission) the prefix of the names of the form (noted "pfx") and the namegiven to the field ("FIELD" in this example).

MOVE ... TO EpfxFIELD

Variable names E... are automatically declared due to the form creation process.

This field must also be enabled for transmission, which is done globally for all fields andcan always be overridden for each field individually.

Note: We also use the terminology "enter a value in a field" for "display a value in afield of a form".

6.2.3.1 Global Transmission Value

This value is defined by the contents of the "transmission value" column in the messageassociated with the exchange (created using GESMES and stored in a SINDIA7 file).Value "O" (letter) specifies that values will be sent for all fields by default. Value "N"specifies the contrary to prevent values from being sent from the application to theterminal.

To override the value stored in the SINDIA7 file, the programming interface consists in thefollowing encoding:

MOVE SINOK TO SINEFF for enabling transmission globally,

MOVE SINNO TO SINEFF for disabling transmission globally.

6.2.3.2 Individual Transmission Value

For each form field, there is an associated variable for individual control of Emission. Thisenables monitoring field by field of the emission in order to (for example) override theglobal transmission value (defined in the above paragraph).

The name of the control variable attached to a field whose name is " FIELD" (for example)is built from the concatenation of the prefix of the names of the form (noted "pfx"), thename given to the field ("FIELD" in this example) and the suffix "- V":


6-6 47 A3 56BB Rev02

pfxFIELD-V

All of these control variables are automatically generated by the form creation processand are combined into what is called a transmission vector.

To force the transmission of a field, you must assign the symbolic value SINVALX1 to itscontrol variable; to disable transmission, you must use the symbolic value SINVALX0.

Therefore: MOVE SINVALX1 TO pfxFIELD-V causes the value ofEpfxFIELD to be displayed in the FIELD field of the screenwhatever is the global transmission value

and: MOVE SINVALX0 TO pfxFIELD-V prevents the value frombeing entered in the FIELD field of the screen, whatever isthe global transmission value.

6.2.4 Modifying a Video Display Attribute

For each variable or fixed addressable field in the form, the form preparation processgenerates an associated variable to handle the video display attributes.

The name of the control variable attached to a field whose name is "FIELD" (for example)to handle the video display attributes, is built from the concatenation of the letter "V" (asfor Video), the prefix of the names of the form (noted "pfx"), and the name given to thefield ("FIELD" in this example):

VpfxFIELD

The video display attribute is encoded using one character, either a letter from "A" to "Y"or a number from "1" to "8". Each code may represent several attributes. For example:

"A" represents" secret"

"B" represents half-intensity + underline + blinking + reverse video.

The code "Z" is used to restore initial video display attributes, in other words, the onesdefined when creating the form.

TPR Encoding

47 A3 56BB Rev02 6-7

The attribute table is set as follows for a monochrome terminal.

ATTRIBUTE SINDIA7 CODE A B C D E F G H I J K L M N O P Q R S T U V W X YSECRET Y N N N N N N N N N N N N N N N N Y Y Y Y Y Y Y Y1/2 INTENSITY N Y Y Y Y Y Y Y Y N N N N N N N N Y Y Y Y N N N NFULL INTENSITY N N N N N N N N N N N N N N N N Y N N N N N N N NUNDERLINE N Y Y Y Y N N N N Y Y Y Y N N N N Y Y N N Y Y N NBLINKING N Y Y N N Y Y N N Y Y N N Y Y N N N N N N N.N N NREVERSE VIDEO N Y N Y N Y N Y N Y N Y N Y N Y N Y N Y N Y N Y N

To handle these video display attributes, it is preferable to use the symbolic values:

SINVALXA, SINVALB, ..., SINVALXZ, SINVALX1, ..., SINVALX8

For example, to notify the reverse video attribute, you program:

MOVE SINVALXP TO VpfxFIELD

The value SINVALXZ is used to restore the initial video display attributes, in other words,the ones defined when creating the form.

To restore the video display attributes for all the fields of a form at once, you assign thevalue SINOK to the variable SINVIDIN.

MOVE SINOK TO SlNVIDIN

You should remember that video display attributes are handled independently fromtransmission vectors and SINEFF. In other words, you do not have to retransmit a field ifyou want to modify its video display attributes.

The table below explains the different ways the DKU 7211 can be configured.

• 7-color configuration• 4-color plus underline configuration• 4-color plus blinking configuration• Monochrome configuration (DKU 7107).

The following abbreviations have been used in the above tables:

1/2 for half intensitynor for normal intensitysec for secretul for underlining^ for blinkingrv for reverse video


6-8 47 A3 56BB Rev02

For SINDIA7 codes "R" through "8", the "secret" attribute applies. This means:

• Either the background is the color specified and the terminal does not display what theend user enters (example: for "R" in 7 colors: the background is red and the dataentered are "secret").

• Or the background is white or black (depending on whether the terminal screen isconfigured for positive or negative display) and the cursor is the color specified. Theterminal does not display what the terminal operator enters (example: for "S" in 7colors: the background in white or black depending on the terminal configuration, thecursor is red and the data entered are secret).

Note: Key "?" in the input field to obtain help in defining display attributes and color; ahelp screen then appears.

In return, a second character appears (letter Q = return to normal display).

The last field on the last line (24th) can not exceed column 78, as column 79must contain the letter Q and column 80 is reserved for the letter D (forDESIGN).

The character _ (underscore) is used to delete the display attribute.

TPR Encoding

47 A3 56BB Rev02 6-9

7 c olo rsB ac k C har

4 c olo rs + underlineF ond C har

4 c o lors + b lin k ing M onochrom eS IN DIA 7c ode B ack Char

BCDE

FGHI

JKLM

NOPQ

RSTU

VWX

Y = A

1234

5678

Black

R ed

B leu

C yan

M ag enta

G reen

Y ellow

W hite

R ed

C yan

G reen

W hite

B lack

W hite

M ag enta

Y ellow

B lac k

R ed

B leu

Cy an

M agenta

G reen

Y e llow

W hite

R ed

Cy an

G reen

W hite

B lac k

W hite

M agenta

Y e llow

SECRET

SECRET

SECRET

SECRET

R ed

C y an

R ed

C y an

G reen

W hite

G reen

W hite

C y an

C y an

W hite

W hite

R ed

R ed

G reen

G reen

R ed

C yan

R ed

C yan

G reen

W hite

G reen

W hite

C yan

C yan

W hite

W hite

R ed

R ed

G reen

G reen

R ed ^

R ed ^

Cy an ^

Cy an

G reen ^

G reen

W h ite ^

W h ite

R ed

Cy an

G reen

W h ite

R ed

Cy an

G reen

W h ite

R ed

R ed

Cy an ^

C yan

G reen

G reen

W hite ^

W hite

R ed

C yan

G reen

W hite

R ed

C yan

G reen

W hite

1 /2 u l ^ r v1 /2 u l ^ 1 /2 u l rv1 /2 u l

1 /2 ^ rv1 /2 ^ rv1 /2 rv1 /2

nor ul ^ rvnor ul ^ rvnor ul rvnor ul

nor ^ r vnor ^ nor rvnor

s ec 1 /2 u l r vs ec 1 /2 u l s ec 1 /2 u l s ec 1 /2 rv

s ec u l r vs ec u ls ec rvs ec

s ec 1 /2 u l ^ rvs ec 1 /2 u l ^s ec 1 /2 u l ^ rvs ec 1 /2

s ec u l ^ rvs ec u ls ec ^ s ec ^


6-10 47 A3 56BB Rev02

6.2.5 Recap

We are using a form with:

• a global prefix "pfx"

• variable field namesare "FIELD1", "FIELD2", etc.

C U R S OR p os itionS IN C U R = N ° o f f ie ld

G lob a l v a lu e fo r em iss ion :SINEFF- S IN O K em it- S IN N O don 't em it

E m ission v e ctor

- S IN V A LX 1 e m it- S IN V A L0 d on 't em it

p fxF IE LD 1-Vp fxF IE LD 2-V. . .

V a lues to e m it

E pfx F IE LD 1E pfx F IE LD 2. . .

R E M A R K fie rld : se e b e low

G lob a l res to ra tion o f in itia l v ide od isp lay: S IN V ID IN- S IN O K res tore

v ide o d isp lay a ttribu te v ec tor

- SINVALXA,B,.. . Y, 1...8- S IN V A LX Z res tore

V p fxF IE LD 1V p fxF IE LD 2. . .

EMISSION V ID E OA TTR IB U TE S

O R D E R P A R A M E TE R

R E M A R K

F IE L D 1

F IE L D 2

... ...

RECEPTION

SINTRYSINPARRpfxZONE1RpfxZONE2...

f ie ld n° 0fie ld n° 1fie ld n° 3fie ld n° 4 ...

(C O M M A N D f ield -O R D E R )(P A R A M E TE R field )(F IE LD 1)(F IE LD 2)...

IMPORTANT

Th e R E M A R K fie ld (f ie ld n ° 2 ) is nev e r rec e iv ed

TPR Encoding

47 A3 56BB Rev02 6-11

6.2.6 Example

6.2.6.1 Specifications

The example consists of an exchange in which the end user enters a quantity expressedin hours and minutes which is to be converted into seconds. The number of hours mustbe less than 24 and the number of minutes less than 60. The form used features twovariable fields HH and MM as well as a fixed addressable field SSSS. The number ofseconds is displayed during the next exchange. Both exchanges use the same form.

6.2.6.2 SINDIA7 analysis sheet

ExchangeNumber

Level Processform

Chaining Description

1 0 GR5 Enter the number of hours andminutes

T PSIN1

2

1

Test the values entered (hours < 24,minutes < 60)

If OK

- calculate number of seconds- reset hour and minute fields to blank- prepare display of number of seconds- go to exchange 2 with message 2000

Else

- set incorrect field or fields to reverse video- position cursor on first incorrect field- do not modify values entered- remain in same exchange- transmit error message 1000

2 0 GR5 ...

T PSIN1 ... ...

The transmission value of error message 1000 is " N" . The transmission value ofmessage 2000 associated with exchange 2 is "0". The prefix "GR5-" was used whendefining the form GR5.


6-12 47 A3 56BB Rev02

6.2.6.3 Programming

PSIN1 NOTES

MOVE SINOK TO SINVIDIN 1

PERFORM TEST. 2

GOTO OK 3 ERR-HH ERR-MM ERR-HH-MM DEPENDING ON TEST-RES.

OK. COMPUTE EGR5-SSSS = (RGR5-HH * 3600) + (RGR5-MM * 60) 4

* RESET HH and MM TO BLANK 5

MOVE 2 TO SINECH 6 MOVE 2000 TO SINNUM 7 GO TO FSIN1.

ERR-HH

MOVE 3 TO SINCUR 8 MOVE 1000 TO SINNUM 9 MOVE SINVALXP TO VGR5-HH 10

GO TO FSIN1. ERR-MM. MOVE 4 TO SINCUR 11 MOVE l000 TO SINNUM 9 ...

ERR-HH-MM MOVE 3 TO SINCUR 8 MOVE l000 TO SINNUM 9... MOVE SINVALXP TO VGR5-HH, VGR5-MM 12...

6.2.6.4 Explanations and Comments

1. The initial video attributes are restored at the beginning of processing regardless oftest results. This is to make sure that the screen is correct in the event an error iscorrected and in the event there are successive errors:

• when you iterate on exchange 1 due to successive errors, only the incorrectfields are in reverse video,

• when coming from an error occurrence (therefore with fields in reverse video)and there is no more error, you chain to exchange 2 while suppressing thereverse video attributes.

TPR Encoding

47 A3 56BB Rev02 6-13

2. The TEST paragraph performs the tests desired and returns the result in the TEST-RES variable:

0: no error1: error in hours2: error in minutes3: error in hours and minutes

3. Branch according to TEST-RES

4. Conversion (calculation based on fields received R..., result in E...).

5. The hour and minute fields are reset to blank on the screen automatically, withoutprogramming.

The global value for emission is "0". The fields of the form receive the values of the "E..." variables. These variables are by default correctly initialized. It is thereforeuseless to explicitly program:

MOVE SPACES TO EGR5-HH E GR5-MM

6. Chaining to exchange 2. There is nothing special to do in order that values areentered for the HH, MM and SSSS fields since the transmission value of theassociated message (2000) is "0".

7. Chaining to exchange 2 is done while message 2000 is displayed.

This instruction is useless if message 2000 is attached to exchange 2, when definingexchange 2.

8. Set the cursor on field No. 3, that is, on the 1st "user" field in the form.

9. Message 1000 display. Since its transmission value is "N", the screen fields will notbe modified.

10. Set HH field to reverse video. No need to set SINECH which already equals 1. Youremain in the same exchange.

11. Setting of the cursor on the MM field.

12. Set to reverse video the HH and MM fields.

6.2.7 Message Handling

Messages are generally stored in a SINDIA7 file and are defined using GESMES. Youcan also define them fully by program, but this should be used only exceptionally. TheSINDIA7 variable SINMOD indicates where it originates from:

MOVE "F" TO SINMOD Message on File (default value)

MOVE "U" TO SINMOD Message defined in a processing operation.

Implicitly, the message which appears in the REMARK field is the one which wasspecified when the exchange was defined. The SINNUM variable is used to displayanother message (in the event of an error, for example).


6-14 47 A3 56BB Rev02

The global transmission value of fields can be overridden at the global level by the valueassigned to SINEFF (SINOK enabled, SINNO disabled) as well as at the basic pfxFIELD-V level (SINVALX1 to enable transmission, SINVALX0 to disable it).

The cursor position is handled by SINCUR (starting at zero).

There are also two variables used to control cursor position, SINA and SINB, according tothe formula:

new SINCUR = SINA *SINCUR + SINB

This is useful to position the cursor on a table element.

When the message is not in the SINDIA7 file, the programming interface consists ofgiving values to the following SINDIA7 variables:

SINMOD: " U"SINLIB : message textSINCAR: message skeleton parameter setting characterSINCHG: replacement value in the message.

6.2.8 Command Authorizatlon

With each command "xxx" is associated a command authorization indicator Sxxx.

SINOK enables the command, SINNO disables it.

The only exception to this naming convention concerns the command END (F) whoseauthorization flag has SF for name. By default, END (F) is enabled, therefore SF equalsSINOK.

There is no indicator for CAN (ABT), HLP (SVP) and RPT (BIS).

By default, user commands are disabled. You must therefore remember to enable thembefore using them.

Insofar as enabled commands vary from one exchange to the next, it is good practice tocombine the programming for chaining and command authorizations in a single COBOLparagraph.

TPR Encoding

47 A3 56BB Rev02 6-15

Example:

PSIN2. ... ... PERFORM CHAIN-3FSIN2.

...

PSINCOM.

...

CHAIN-3 MOVE 3 TO SINECH MOVE SINOK TO Sxxx, Syyy,... MOVE SINNO TO Saaa, Sbbb,...

6.2.9 Commitment Unit Handling

This point is essential for good performance and is covered in the chapter entitled"GCOS7 Environment Optimization".

SINDIA7 transactions must imperatively be generated with the "IMPLICIT COMMITMENT" clause. The explanations below are onlymeaningful in this context.

The SINLOP variable controls commitment unit management; it can take the values:blank, 0, 1, 2, 3, 4.

6.2.9.1 Normal case (SINLOP=" ")

Each end of exchange results in a commitment; this is done by default withoutprogramming, as the SINLOP variable is loaded to blank at the beginning of eachexchange.

Outline:

PSINi TRT-i MOVE j TO SINECH

FSINi commitment, display of the form attached to exchange j, conversation

PSINij TRT-j ...


6-16 47 A3 56BB Rev02

6.2.9.2 Chaining of exchanges without commitment (SINLOP = 0)

At the end of the exchange (i), the program chains to the next exchange (j) withoutcommitment. This type of programming is not recommended as it blocks the resources foran undetermined amount of time (during a conversation) and causes a LONG WAIT forthe other users waiting for the resources being used by exchange i.

Outline:

PSINi TRT-i MOVE J TO SINECH MOVE O TO SINLOP

FSINino commitment, display of the form attached to exchange j, conversation

PSINj TRT-j ...

6.2.9.3 Chaining to an indirect exchange with intermediate commitment (SINLOP = 1 )

This facility is used to free resources when you use the indirect exchange facility. It is thefunctional equivalent of programming:

MOVE SINOK TO SECH

Outline:

PSINi TRT-i MOVE j TO SINECH MOVE 1 TO SINLOP

FSINicommitment, no form display, no conversation

PSINj TRT-j ...

TPR Encoding

47 A3 56BB Rev02 6-17

6.2.9.4 Chaining to a non-SINDIA7 TPR with intermediate commitment and return to a SINDIA7exchange (SINLOP = 2)

This facility is used to mix SINDIA7 TPRs with non-SINDIA7 TPRs while controllingcommitment:

Outline:

PSINi TRT-i MOVE j TO SINECH MOVE 2 TO SINLOP MOVE tpr TO NEXT-TPR

FSINicommitment, no form display, no conversation

tprcommitment (depending on tpr), display of form attached to exchange j, conversation

PSINj TRT-j

Note that functionally this construct is like using the non-SINDIA7 TPR as a subroutineand could have been programmed using "CALL".

6.2.9.5 Chaining to an indirect exchange without intermediate commitment (SINLOP = 3)

This possibility is an addition to case "SINLOP = 1" when chaining between exchanges iand j, there is no commitment. Resources are not freed when chaining to processingoperation j.

6.2.9.6 Chaining to a non-SINDIA7 TPR, without intermediate commitment and return to a SINDIA7exchange (SINLOP = 4)

This possibility is an addition to case "SINLOP=2". There is no commitment whenchaining between processing operations j and the non-SINDIA7 TPR.


6-18 47 A3 56BB Rev02

6.2.9.7 Note: using CAN (ABT) and END (F) commands

Caution. Using these commands results in the end of the current level i exchange andthus causes commitment.

The dynamic outline is:

• beginning of exchange i (the attached form is displayed)

• the user enters END (F) or CAN (ABT) and "transmit",

• SINDIA7 reroutes to PSINF (provided that END (F) is enabled) or PSINABT (PSINIprocessing is not executed) and causes commitment.

6.2.10 Receiving the current transaction name

In variable SINTRZ

6.2.11 Clearing the screen

This function is only available for the END (F) command (paragraph PSINF) and iswritten:

MOVE SINOK TO SINCLEAR

6.2.12 Number Check

A routine is provided ("SINPRONU"). Refer to the on-line documentation (chaptercovering encoding).

TPR Encoding

47 A3 56BB Rev02 6-19

6.3 REFERENCE

The table below is a reference table for SINDIA7 encoding. You should use it whenencoding exchanges.

Variable FunctionPossible values (initialization name

value),modification: explanationSINECH Exchange number From 1 to 99 (1 at the beginning of the

transaction)Modification: MOVE n TO SINECH

SECH Indirect exchange flag SINOK: next exchange indirect flagSINNO: next exchange not indirect(SINNO: at the beginning of the exchange and after indirect processing)MOVE SINOK TO SECH: next exchange indirect

SINMOD Message origin "F" : message in SINMST file flag"U": message defined in the processing"T" : message in TABMES table (for compatibility with SINDIA previous version)("F" at each exchange, "T" and "U" only exist forcompatability)

SINNUM Number of the message tobe displayed in theREMARK field

From 1 to 9999 and blank(blank: implicit use of the value entered whendefining the exchange and stored in TABTEC)

SINMASK Screen form identification Up to the programmer's appreciation

SINMES SINMOD and SINNUMgroup field

SINNATIN Indicator for retrieving thefields' initial nature

= SINOK for all fields= SINNO, default value at start of exchange, no retrieval

SINNO Invalidates the field

SINOK Validates the field

SINTRY Reception field in theCOMMAND field (ORDER)

Up to the programmer's appreciation

SINCUR Cursor position (fields arecounted from zero)

From 0 to 191 and blank (blank: implicit use of thevalue defined when creating the message).

SINA,SINB Cursor position in "newSINCUR" = SINA xSINCUR + SINB

Positive integer or null values (SINA to 1, SiNB to 0for each exchange)

SINLIB Text of message in table character string(blank: at the beginning of eachexchange).


6-20 47 A3 56BB Rev02


value),modification: explanationSINCAR Message parameter

setting characterdefined when creating the message (blank: noparameter setting)

SINCHG Replacement value in aparameterized message

loaded by program (blank: at the beginning of theexchange)

RpfxFIELD Receiving screen depending on programmer's declarations (blank)

EpfxFIELD Transmitting screen "field" depending on programmer's declarations (blank)

CpfxFIELD Cursor's symbolicaddressing vector

-MOVE SINVALX1 TO CpfxField

NpfxFIELD Initial nature modificationvector

= SlNOK renders a field protected andnontransmissible= SINNO renders a field variable and transmissible =SINVALXZ restores the initial nature of a field

pfxFIELD-V Enables transmission ofuser's screen "field"

SINVALX0, SINVALX1SINVALX0: do not transmitSINVALX1: transmit (the initialization value dependson the global transmission value defined by themessage displayed on the form or by theprogrammer using SINEFF)

VpfFIELD Value of form field videodisplay attributes

SINVALXA, SINVALXB, ..., SINVALXY, SINVALXZ:restores initial video display

SINPAR Receiving thePARAMETER field

depending on what the terminal operator enters(blank)

SINEF Global transmission value SINNO, SINOK or blankSINNO: default value, transmit nothingSINOK: default value, transmit everything (blank: usethe value contained in the message)

SINVIDIN Initial video display restoreflag

SINOK, SINNOSINOK: restore initial video display for all fieldsSINNO: no modification to video displaySINNO at the beginning of each exchange). Thevideo display vector elements may override thisglobal value.

SINVRERA Delete flag for all variablefields

= SINOK deletion= SINNO no deletion

SINCLEAR Clear screen flag SINOK, SINNOSINOK: clear screenSINNO: no clear screenCondition for use: restricted to END (F)commandin paragraph PSINF (SINNO)

TPR Encoding

47 A3 56BB Rev02 6-21


value),modification: explanationSF END command enable flag SINOK, SINNO (SINOK implicit)

SINOK: "END" enabled (F)SINNO: "END" disabled (F)

Sxxx user command xxx enableflag

SINOK, SINNO (SINNO implicit)SINOK: "xxx" enabledSINNO: "xxx" disabled

SINTRX name of next transaction according to programmer

SINTRZ name of transactioncurrently being executed

to be received by program

SINLOP commitment unitmanagement

blank, 0, 1, 2, 3, 4 (blank at the beginning of eachexchange)blank : commitment at each exchange0 : exchange chaining without commitment1 : chain to indirect exchange with intermediate commitment2 : chain to non-SINDIA7 TPR with commitment and return3 : chain to indirect exchange without intermediate commitment4 : chain to non-SINDIA7 TPR on commitment and return

SINVALXA toSINVALXZ

Value from A to Zexpressing the differentdisplay attributecombinations

SINVALX0 Field without value

SINVALX1 Field with value

SINVALX2 Delete field

PSINi Start of exchange i

FSINi End

PSINX Start of End command (F)

FSINX END

PSINXi Start of i command

FSINXi End


6-22 47 A3 56BB Rev02

6.4 ACCESS TO RECEIVE ONLY PRINTERS

6.4.1 GTWRITER - Overview

To access receive only printers from SINDIA7, the programmer uses the GCOS7 remote-terminal print facility: GTWRITER (Generalized Terminal Writer).

The principle is simple:

• The programmer writes a report in the system library named SYS.TW.OUT usingstandard COBOL commands (WRITE).

• When the report (a member of this library) is finished being written, the print request isqueued with management parameters similar to the ones in SYSOUT reports (class,priority, paper, etc.); the destination is the name of a terminal or a pool of generalizedterminals. The request queue and printout are handled independently from the programwhich created the report. Routing to a terminal or a pool of terminals, paper setup,printing test, incidents and restarts during printout as well as the number of copies to beprinted are all handled by GCOS7. More precisely, these are handled by the printservers which are part of GTWRITER. Even though the programmer is relieved of allthese tasks, he does have the primitives required to check the status of the printrequest run.

Formats supported are: SARF, SSF or ASA.

6.4.2 GTWRITER and SINDIA7/TDS Interfaces

In an exchange, the programmer calls the " H_TW_USTART" primitive to open a report.

CALL "H_TW_USTART" USING TWRITER-FILE TW-REPORT TW-RESULT

The TWRITER-FILE parameter identifies the report name, the TW- REPORT structuredefines the report characteristics and TW- RESULT gives the result of the call (a returnedvalue equal to zero means the call was successful).

Now the programmer writes all the data contained in the report.

The rule to follow is: the H_TW_USTART primitive must be executed in the samecommitment unit as the one in which the report was written, which for SINDIA7 means:

• the report must be created in the same exchange,

• if this is not possible, use SINLOP to "extend" the duration of the commitment unit.

The H_TW_USTART primitive is sufficient to generate a report. The complementaryinformation which follows can therefore be skipped.

TPR Encoding

47 A3 56BB Rev02 6-23

Once the request is queued, if the programmer wishes to follow it (by program) or provideextra information for the end user (for example, the GTWRITER report identification), heuses the "H_TW_UGETR" primitive.

CALL "H_TW_UGETR" USING TW-REPORT

TW_REPORT is a COMP-1 wich is the last report number allocated for the submitter.This number identifies the report and must be provided as an argument in certainprimitives to obtain report status.

Practically speaking, after the exchange containing the last report creation entry and theexplicit commitment request, it is a good idea to encode the call to "H_TW_UGETR" in thenext exchange.

The GTWRITER test structures and primitives are fully described in a separate manualsince GTWRITER services can be accessed from anywhere in GCOS7: transactionally,interactively and during batch processing.

The list of the other primitives for interfacing with GTWRITER is given below forinformation.

H_TW_MAIN provides overall information on GTWRITER

H_TW_UDR provides the status of the job specialized in remote printeroutput (DRIVER): name, ron, etc.

H_TW_UTR to obtain specific information on a terminal

H_TW_UQR to obtain a description of a request and the associated reportin the queue

H_TW_UQN to obtain the same information as with the above primitive butfor the next report in the queue

H_TW_UCOMM to activate a TWRITER command and check how it runs.These commands are the ones an interactive user mightsubmit.

6.4.3 Implementing GTWRITER in SINDIA7/TDS

Refer to the GTWRITER manual for aspects which do not directly pertain to TDS. Theimpact of TDS is felt when generating the TDS since a file is added to the TDS.

You must include the description (SELECT clause) of the SYS.TW.OUT file in the FILECONTROL SECTION in the STDS member of the source library associated with the TDS.

SELECT EXTERNAL filename ASSIGN TO if n

ORGANIZATION IS SEQUENTIAL WITH SSF VLR

ACCESS MODE IS SEQUENTIAL


6-24 47 A3 56BB Rev02

In addition, you must add a FILE DEFINITION clause to the FILE DESCRIPTIONSECTION for this file which is not controlled by TDS.

FD filenameLABEL RECORDS ARE STANDARDRECORD CONTAINS 1 to 256 CHARACTERS01 record-name PIC X(256)

Finally, you must assign this file (ifn) to the SYS.TW.OUT file in the JCL executing theTDS (JFEXETDS member).

6.5 INITIATING COMPILATION

Use JCL JFCRETPR: it chains to linkage extraction, generation, compilation, and editing.If an error is made, use the SCANNER to consult the listing on line. Remember that theCOBOL compiler DIAGIN option can be used to get the diagnostics included in the sourceyou are compiling. In addition, remember that the Sn:p request of the SCAN command isused to display characters starting with column n. This truncating feature prevents linefolding and makes it easier to consult the listing.

The JCL JFEXETDS automatically includes the elements developed by JFCRETPR: eachtime the TDS is initiated, all the modifications ready are included.

6.6 ANALYSIS DOCUMENTATION

The JFCREDOC member of the associated source library is used to obtain the analysisdocumentation set automatically. This documentation set mainly includes:

• the SINDIA7 analysis sheets with comments

• the messages used

• the form designs

47 A3 56BB Rev02 7-1

7. BATCH program skeleton generationtransaction

7.1 PRESENTATION OF THE APPLICATION

BATCH Program Generation is an additional facility in SINDIA7, designed up till now fordeveloping transactional applications for use in a TDS environment.

The product's new functionalities are intended to enable development of classic batchapplications which can be used in any environment, particularly outside the TDSenvironment.

First of all, the main development stages for such an application are very similar to thosenecessary for transaction application development. They require the use of interactivetools (under TDS) and batch procedures (deferred).

What is more, in line with the SINDIA7 functionalities, the aim is to provide a set ofcomplementary services.

• Generation of a COBOL skeleton corresponding to the program's main functions,meaning its Architecture, Kinematics, Pairing and Break management, as well as thechaining of the processing phases.

• Methodological help for studying the problem posed by the program to be developed.

• Provision of organic-type documentation when the problem has been defined (in termsof the parameters necessary for generation).

Lastly, the development tools provided will have the same specific features as fortransaction development:

• On-line documentation adapted to the different interactive or batch procedures andintegrated into the existing documentation. Transactional Applications under GCOS 7

• Integration of a certain number of references (entries, structures, files and processingsequences to be included) in the Data Dictionary when the generation parameters areinput.


7-2 47 A3 56BB Rev02

7.2 GENERAL PRINCIPLES

Generating the skeleton of a Batch program means submitting the problem to organicanalysis. This analysis is based on a detailed method using a certain number of specificconcepts, such as Breaks, Synchronization and Pairing, based on the file kinematics(sometimes called file pairing).

Generally speaking, a batch processing unit is designed to process a flow of data ofvarious types (files or parts of files), grouped into logical sets with the same structure(records).

Specific processing functions will be applied to each logical set, and these will be chainedin an ordered sequence, as a result of the similar nature of the data to be processed. Theprocessing can therefore be seen as a repetition of identical phases, applicable to eachlogical set.

This leads us to define the CYCLE concept to represent the processing phase with thelargest content.

These logical sets, which implicitly define the cycle, and which may be spread over one ormore files, should be considered as specific. It may become necessary, punctually duringthe cycle, to use other data, whether complementary or subordinate to the logical sets.

Thus, an important distinction arises in the set of data to be processed, and it also appliesto the different files present:

• The major files: these are the "KINEMATIC" files which indirectly define the processingmode.

• The secondary files, called "REQUESTED" files, and which do not have any effect onthe definition of the cycle.

Now that this distinction has been established, the Kinematic file records can beprocessed either independently or in "GROUPS". In the second case, any group must bedefined by one or more criteria. Similarly, any group under consideration can be brokendown into Sub-Groups.

The criteria are characteristic information which can either be directly available in the flowof data to be processed, or defined during the cycle by appropriate processing.

The event corresponding to a processing cycle on a new group of data (i.e. change in thevalue of the associated criterion) is called a BREAK.

The concept of Groups and Sub-Groups leads us define several Break levels, eachinduced by specific criteria called:

• READ criteria if they are immediately available

• COMPUTED criteria if specific procedures are necessary before they can be used.

The Group concept can be extended to Records with different structures, from differentfiles, but capable of being gathered together. These records will be processed individuallyin a similar way, or as a logical set, made up of several records of various origins, by aspecific processing function.

BATCH program skeleton generation transaction

47 A3 56BB Rev02 7-3

In the first case, although the Group concept remains linked to the Break concept, theorder in which the records involved are taken into account must be based on specificcriteria.

In the second case, a Group is seen as the set of records which can be associated. Thereare criteria defining this situation, called SYNCHRONIZATION.

In general, these criteria, which affect the order in which the records are taken intoaccount according to their origin, are called Synchronization Criteria.

As with the Break concept, several Synchronization levels can be defined on the basis ofcriteria which are either:

• READ

• or COMPUTED

NOTE

Synchronization (or Non-Synchronization) is the event resulting fromthe pairing of several files.

Lastly, if the Synchronization and Kinematics interfere with one another, every break is anindependent phenomenon. In spite of all this, Breaks and Synchronizations can bemanaged simultaneously with a set of specific criteria.

On the basis of these considerations, the following comments can be made:

• It is the reading of a record which determines whether a Break situation is present.

• If we consider that a Break can determine a group of records, but that a single record isavailable at a given time, 2 totally independent types of processing can be described.These processing routines will be executed at different moments, with differentfrequencies.

For any Break level defined, different types of phases are possible:

• TOTAL processing phases which can be applied to groups of records.

• DETAIL processing phases which only involve the record taken into account in thecycle.

Any break or non-break can be considered at the detail level only as an event (a Non-Break is of no significance at the Total level). An event of this sort can be translated interms of Conditions.


7-4 47 A3 56BB Rev02

However, any group in terms of pairing implies the availability of all the records in thegroup. Here too, Synchronization is only considered as an event. Synchronization andNon-Synchronization can only be involved in a Detail phase if the Break concept ispresent.

It is now possible to represent a standard batch program schematically, using theconcepts presented above.

IN IT IA L E p hase b e fore the f irs t record is read

F ILE A C C E S S p hasefor read in g a s ing le record p er f ile

S YN C H R O N IZ A TIO N D E TE R M IN A TIO N p hase w h ich m ust in fe r the re cord to b e taken in to accoun t in the cyc le ( log ica l f ile )

B R E A K D E TE R M IN A TIO N ph ase us ing the da ta in the L og ica l F ile

N TO TA L P R O C E S S IN G p ha se s on e pe r b reak lev e l de fin ed

M D E TA IL P R O C ES S IN G p hasesea ch linked, if n ecessa ry , to certa in S ynchron iza tio nor b reak co nd itions

F IN A L P rocess ing p ha seafte r the las t re co rd h as b ee n re ad

.

.

.

.

.

.

.

C YC LE

Like the TPR skeleton generator supplied in the transactional part of the SINDIA7 product,the batch program generator is designed to set up a structure of this type, and handle thechaining of the processing phases, as well as the whole of the following phases...

• Access to the Kinematic files

• Determination of the synchronizations and the Logical File

• Determination of the breaks

The developer simply inserts the COBOL code corresponding to the processing containedin the Initial, Total, Detail and Final processing phases.

This type of generation nevertheless requires input of a set of parameters, some of whichmay be optional.


47 A3 56BB Rev02 7-5

These parameters are:

• The name of the Processing Unit

• the definition of the Kinematic Files

• the definition of the Requested Files

• the working structures

• the linking structures

• the processing sequences to be incorporated

• the definition of the Break identifiers

• the definition of the synchronization identifiers

• the definition of the Processing Phases

• the definition of each of these processing phases (necessary for provision of theorganic documentation)

• the conditions for selecting the records in the kinematic files.

7.3 THE FUNCTIONALITIES

Implementation of the SINDIA7 BATCH generator involves three main functionalities:

• Management of generation parameters

• Generation of the COBOL program

• Output of the organic-type documentation

7.3.1 Management of the generation parameters

This phase is performed in transactional mode under the SINDIA7 TDS, using thefollowing functions:

• CREATION of a non-generated SINDIA7 BATCH SOURCE, which means inputting theparameters for generation of a new COBOL source.

• MODIFICATION of a non-generated SINDIA7 Batch source

• CONSULTATION of a non-generated Source

• Source DELETION


7-6 47 A3 56BB Rev02

• DUPLICATION of a non-generated SINDIA7 Batch Source, which consists in creating anew Source from an existing one.

7.3.2 SINDIA7 Batch Source generation

This contains a single phase executed in BATCH and during which we constitute:

• a program (Y Source name)

• a skeleton (X Source name)

• the Data Dictionary structures.

The program Y <Source name> corresponds to the general architecture of the Batchprocessing, in line with the parameters defined. It contains all the file kinematics:

• file declaration and opening of declared files

• reading of kinematic files

• chaining of the processing in line with the conditions defined

• call of the processing skeleton (X <Source name>)

IMPORTANT

This program is the core of the batch processing. The user must neverchange Y <Source name>. With GESPRG you can modify the filekinematics of Y source name.

The processing skeleton (X <Source name>) is a library member, called by COPY in theprogram. It contains all the processing references defined as parameters:

• INITIAL

• FINAL

• TOTAL (by break level)

• DETAIL (by declared sequence)


47 A3 56BB Rev02 7-7

Only this skeleton requires completion by the user, who must enter the COBOL codecorresponding to the referenced processing by means of the text editor.

Notes : 1.Unlike the TPR generator (GENTPR), the BATCH processing skeleton isdirectly modifiable after generation (GENPRG), without any preliminarymanipulations.

2.Comment on X <source name>:

In the case of a "regeneration" after parameter modifications, the member X<source name> is modified by comparison of the existing parameters and thenew parameters defined, so that the COBOL code already input for existingprocessing is not lost.

The Data Dictionary structures: when describing the working and linkage areas, it ispossible:

• either to use the structures already defined in the SINDIA7 dictionary

• or to create new structures in the dictionary.

The new structures in the SINDIA7 dictionary are only created at the moment ofgeneration.


7-8 47 A3 56BB Rev02

7.3.3 Editing the program documentation

In a single BATCH phase

G E S P R G

S IN L IP B

S IN P R G BS IND IC S IN R U B

G E N P R G

SIN W R K B S IN S R C B X ---

(op tiona l)

S IN LN K B

Y--- S IN C O D B S IN JC L B

These 5 f ile s S IN SR C BS IN C O DBS IN JC LBS IN W R KBS IN LN K B

are tem p orary


47 A3 56BB Rev02 7-9

S IN P RG B S IN D IC

S IN R U B

G E S P R G

E ntrie s an d s truc tu re s

D a ta D ic tio na ry

K e yb oa rd-S cree n

P a ram eters fo r B atchP rog ram G en eration

With the GESPRG transaction, you can enter all the parameters for Batch programcreation.

It is possible to:

• Create a non-generated source

• Modify a non-generated source

• Consult a non-generated source

• Delete a source

• Duplicate a source.


7-10 47 A3 56BB Rev02

S IN L IP B

SIN W R K B

S IN S RC B

S IN LN K B

SIN C O D BS IN JC L B

G E S P R GS IN PR G B

S tand ard Ba tch G enera tion L in es

P aram eters fo r B atchP rog ram G enera tion

G en era te d C O B O LP rog ra m

S truc tu re

C om p lem entaryG e nera tion JC L

G en era ted S IN D IAS ource (ske le ton)

N ew W S S S truc ture N ew L IN K A G E S E C TIO N

GENPRG is the batch program run to generate the COBOL lines in the source programwhose parameters were input by GESPRG.


47 A3 56BB Rev02 7-11

S IN E D IB

S IN P R G B

P aram eters fo r B atchP ro gram G en era tion

E D IP R G

S IN D P G BD ocum enta tion P rog ram m eB atch

S tanda rd lin es o f B atch P rog ramD ocum enta tion p rin tou t

Editing the documentation of a batch program using EDIPRG program.


7-12 47 A3 56BB Rev02

7.4 DEVELOPMENT OF A BATCH PROCESSING ROUTINE UNDER SINDIA7

The analysis of the batch processing to be performed should deal with several key points:

1. The Kinematic file(s) (up to 4 can be defined) which are the basis for the batchprocessing to be performed

2. Any links between these files:

- Synchronizations (up to 4 levels)- Breaks (up to 4 levels)

3. The main processing to be performed in line with the Synchronization and/or breakcriteria.

Once the analysis has been made, the user must enter all the parameters necessary forgeneration, by means of the GESPRG function.

7.4.1 The KINEMATIC files

In any batch processing routine, the records containing the data to be processed aredelivered to the program in a particular order (a KINEMATIC) which takes into account:

• the nature of the processing to be performed• the content of the files, their organization and the relations which may or may not exist

between these files.

The files are processed

• either independently from one another• or by pairing them according to defined criteria.

The files which infer the order in which the records are delivered to the program, andtherefore the organization of the processing, are called KINEMATIC files. These arenecessarily MAJOR files.

The SINDIA7 BATCH Generator accepts up to 4 Kinematic files.

To execute the program, more than 4 files may be necessary, so the user has thepossibility of defining 20 other files. These files do not have any role in the organization ofthe processing.

They are simply complementary or REQUESTED files, since they are "requested" foradditional data by the kinematic files.

The subject of the following sections is the KINEMATIC files which are the basis for anumber of different functions.


47 A3 56BB Rev02 7-13

7.4.2 The links between files

If we take a file containing n records:

There are 5 cases requiring consideration:

A g iv en typ e o f p rocess ing can b eap p lied n tim es to th is f ile , w h ichm eans n rep etitions o f the sam ep rocess ing .

You m ay w an t to p ro cess a G R O U P o frecords (= a se t o f records linked b yon e or m ore C R ITER IA ).

It m a y be n ecessa ry to p rocesssev era l f iles success iv e ly in the sam ew ay: the f ile p rocess ing w ill th ere foreb e L IN E A R . W e w ill o n ly b eg inp rocess ing the records o f a g iv en f ilew he n th e las t record o f the p rev iousfile ha s b een p rocessed.

1 .

2 .

3 .

F IL 1

123

.

.

.

.n

g roup s

F IL 2

F IL 3

.

.

.

.

F IL 1


7-14 47 A3 56BB Rev02

The c rite ria a re da ta ind ica tingw he th er the record is to be taken in toaccoun t, and in w h at con d ition(b e long ing to g rou p y o r y + 1 ).There are 2 typ es o f c rite r ia :

Those corre spo nd ing to e lem entsin the record : the se a re ca lle dR E AD crite ria .Those de term ined b y fo rm ulae orp roce ss ing rou tines : these areca lled C O M P U TE D crite ria .

It m ay be n ecessa ry to p rocess f i lesin p ara lle l o r s im u ltaneou sly . P rog ressw ith in the f ile w ill b e ordered in lin ew ith c rite ria ca lle d s im u lta ne ity c rite r ia .These f iie s w ill there fore b e p rocesse din p ara lle l.

F IL 1 F IL 2 F IL 3

4.

5 .

a)

b )

On the basis of these different points, it can be said that:

• n records can belong to n groups m groups can belong to x files n records ( m groups (x files.

• When file processing is LINEAR, groups can be determined according to precisecriteria. These criteria will determine the BREAKS.

The term "BREAK criterion" will be used below.

It is possible to define up to 4 break levels, if necessary.


47 A3 56BB Rev02 7-15

Example 1

We want to count products with totals per family and sub-family.

There will therefore be several sub-totals for each product family (a total of 1 persubfamily), with a family total produced each time we change family. In this case there willbe 2 break levels:

• Ievel 1 for the sub-family

• Ievel 2 for the family

With simultaneous advance of the files, we will determine groups according toSYNCHRONIZATION criteria.

It is also possible to have up to 4 levels of synchronization.

Example 2

We have a customer file and an order file.

We want to retrieve all the orders linked to a customer.

We will read the orders for each customer.

We will only move on to the next customer when all the previous customer's orders havebeen examined.

There may be customers without any orders. In this case, we will move on to the nextcustomer.

Here, the synchronization will be provided by the customer number, which means that wewill only process the records if the customer number identifier is identical in both thecustomer and order records.

The order file will change faster than the customer file and is more detailed. It shouldtherefore be declared as a "Primary" file.

ORD (orders) CUS (customer)CDNOCLI CDNOCDE CLNOCLI CLADR

1 87010 08825 A 85850 Bourges2 87010 08858 B 87010 Vire3 87010 09112 C 82220 Paris 10ème4 88220 07533 D 90500 Tours5 91320 08728 E 91320 Chartres6 91320 08790 F 91330 Pau

For the ORD file, the level-1 synchronization criterion is CDNOCLI (read criterion), and forthe CUS file, the level-1 synchronization criterion is CLNOCLI (read criterion).


7-16 47 A3 56BB Rev02

Execution of the processing:

1. Read the first CDE record and the first CLI record.

2. Compare the CDNOCLI and CLNOCLI criteria

• If they are equal:

we move on processing of the synchronization, and then read ORD before returning tophase 2.

• If they are different:

we determine the smaller of the two and read the corresponding file beforereturning to phase 2.

In this example, the reading order will be:

1, A, B , ↓

2 , ↓

3 , ↓

4, C , ↓

5, D, E , ↓

6 ↓

end ofprocessing

PROCESSING ON SYNCHRONIZATION

In this case record F will never be read as the Primary file is finished.

Example 3

O rder

File

R ecords(key)

O r 3 fi les w ith rec ords to beprocessed ident ically

1

A

11

13

-

14

-

2

B

11

12

13

-

15

3

C

11

12

13

14

-


47 A3 56BB Rev02 7-17

R ecords

Files 1 (A)

1113131313131414---

2 (B)

1111121213131315---

3 (C)

1111111212131313---

Condi t ions

B / SB / SB / SB / SB / SB / SB / SB / S

---

P rocessing

11(A)11(B)11(C)12(B)12(C)13(A)13(B)13(C)

---

B = B reakB = N on-B reakS = S ynchronizationS = N on-S ynchronization

Comments on the Breaks

• the file(s) must sorted according to the break criteria.

• the files will be processed in the order in which they are declared.

Comments on the Synchronizations

• To process the files in synchronization, they must be sorted according to the samesynchronization criteria.

• The order in which the files are declared must correspond to their degree of detail, withthe most detailed declared first (in example 2, the first file must be the order file, andthe second must be the customer file).

IMPORTANT GENERAL COMMENT

Only files sorted In ascending order of the criteria (key) can beprocessed.

If we have defined Break or synchronization criteria, it is because we want to applydifferent processing to the records according to the "categories".

It is therefore possible to make the processing conditional on the existence or absence ofBreaks or Synchronizations.


7-18 47 A3 56BB Rev02

If we reconsider example 1, we can produce a breakdown of the processing:

INITIAL : initialization of the counters

DETAIL processing on each reading of a record in the same sub-family, incrementation of the Sub-family counter. Thisprocessing is called the DETAIL processing.

TOTAL 1 : processing for the end of a Sub-family: display of the Sub-family counter, addition to the family counter andreinitialization of the Sub-family counter at zero.

TOTAL 2 : processing for the end of a family: display of the familycounter followed by its re-initialization. This processing iscalled TOTAL processing on a level-2 break.

If we had wanted an overall total of all the families, we would have had FINAL processingwhich would mean that after its execution, the program would be terminated.

The user must therefore take great care in his analysis to ensure that the followingquestions are answered:

• which files are to be processed ?

• how are they to be processed (linear, simultaneous) ?

• what are the criteria which can determine the processing ?

• what are the types of processing and when can they be executed ?

After this analysis, the user simply enters the parameters using the SINDIA7 transaction:GESPRG.

GESPRG

This transaction is executed under SINDIA7 TDS. It contains several screen forms forentering all the parameters of the program to be generated. Certain screen forms can berepeated several times if necessary. There is on-line documentation which can beconsulted for each screen form (it is activated by input of SVP in the command field of theSINDIA7 screen header). Each screen is used for describing a particular part of theprocessing. All the screens can either be displayed successively or selected by enteringthe command SEL and a parameter identifying the screen form (2 letters); this applies toCreation, Modification and Consultation.


47 A3 56BB Rev02 7-19

Screen name Function Identification

BA00 General Menu

BA01 Identifier ID

BA02 GCOS files FI

BA04 Working area WS

BA06 Table TB

BA08 Linkage area LK

BA10 Common Processing TC

BA11 Kinematics CI

BA12 Synchronizations CN

BA13 Break RP

BA14 Definition processing TR

BA15 Detail definition processing "

BA16 Initial processing DT,I

BA17 Final processing DT,F

BA18 Total processing / level DT,T,n (1 to 4)

BA19 Detail processing DT,m (1 to 40)

BA20 Selection condition CD

BA21 Source deletion

BA22 Source duplication

BA23 Screen form selection


7-20 47 A3 56BB Rev02

The transaction's different screen forms

All these screens correspond to the SlNDIA7 norms: there is therefore a "header" forentering commands (ABT, VAL, SVP, etc.) and parameters, as well as a comment fieldwhere messages are displayed. The other lines in the screen are used to input theparameters required for batch program generation.

BA00 Management of the batch programs.

This screen form is used to define the action to be performed(Creation, Modification, Consultation, Deletion andDuplication) on a given batch program (non-generatedsource).

BA01 Identification .

Used to give an object program name (i.e. PROGRAM-ID).The name of the program generated is <source name>, sothe user can give this name (Y <source name>, if he wishes.The user has up o 10 comment lines for defining the purposeof the program.

BA02 GCOS files.

It is possible to define 24 GCOS files, with their mode of use,and they are divided into 3 groups:

• 1 primary file.

• 3 secondary files.

• 20 additional files

All the batch processing will be based on the 4 kinematic files(particularly the primary file).

If the primary file is the only file defined, it is only possible todefine breaks, if required.

If one or more secondary files are defined, it is possible todefine synchronizations .

These 4 files will be processed in the order in which they aredescribed.

IMPORTANT

If one or more synchronizations have to be defined, the files mustdescribed i the order of their degree of detail, and sorted inascending order of the same criteria before processing.

Their mode of use will either be Input (read only) or Update. If necessary, this can bemanaged manually.


47 A3 56BB Rev02 7-21

BAO2 (contd.)

• It is possible to define 20 other files which are whollymanaged by the user, except for opening, whichdepends on each file's mode of use.

For these 20 files, all the modes are possible: Input (readonly), Output (write), Update and Extend.

• During generation:

If the mode of use is input for a file (whatever its type),the corresponding OPEN and CLOSE commands aregenerated.

The reading of the 4 Kinematic files is generated, but ifthey are declared with Update mode, re- writing remainsthe user's responsibility.

No reading or writing on the other 20 files is generated,so the user has total responsibility for their management.

• A declarative COPY can be included.

BA04 Working-Storage

The Working-Storage can be defined using:

• structures already defined in the dictionary

• By creating a new structure and inputting the datacomposing it

• By defining the data by its level, name, format with aredefinition, if necessary, othe the "OCCUR" and"VALUE" clauses.

There can be up to 6 referenceable structures.

• During generation:

If there are existing structures, a COPY of the structureis generated.

If the structure needs to be created, a COPY is alsogenerated and the structure is created in the DataDictionary.

The references in the data dictionary are updated at thelevel of the structures.

BA05 If there is not enough room to input the Working-Storage dataon screen form BA04, there is looping on form BA05 (up to10 times).


7-22 47 A3 56BB Rev02

BA06 The tables (Working-Storage)

It is possible to define 3 tables with 3 sets of dimensions.

For each table. we must define:

• a table name:A name is given for each dimension defined.

• number of elements:The total number of elements defined for the 3dimensions must be between 1 and 32 inclusive.

• length and type:only filled in for the last dimension defined.

• index name:It is possible to define the names of the indexes used forused for each dimension.

BA07 Continuation of content:

It is possible to define what there will be in each element, withone line per element defined (maximum 32).

IMPORTANT

The occurs defined are never refereed to in the Data Dictionary. Theyare strictly Internally defined. They cannot be used with anotherprogram.

BA08 Linkage area

BA09 Used to define a Linkage section. The specifications are thesame as for Working-Storage (BA04R and BA05).

IMPORTANT

Levels 01, 77 and 88 are forbidden as are VALUE statements.

BA10 Common processing

On this level, all the COBOL procedure COPYs used in theprogram's common processing are entered.

During generation, there will be a series of COPY "processingname" commands.


47 A3 56BB Rev02 7-23

BA11 Kinematics

It is possible to work on indexed files. Here the name of theindex from which the file is read, and its type (Primary orSecondary) are given. Otherwise the file is considered assequential.

BA12 Synchronization (per level 1 to 4)

This screen is used to define, for each kinematic file, the listof the entries involved in the composition of thesynchronization criterion. The number of entries that can beused to describe this criterion ranges from 1 to a maximum of4.

There are 2 types of criteria:

• READ if they are obtained by reading a record:

either directly

or after concatenating several entries

• COMPUTED if processing must be executed to give thecriterion a value.

If each file's criteria are read, their total size must be input -meaning the sum of the sizes of each entry defined for a file(the criterion will be of the same size for each file).

If the criterion for one of the files must be computed, its nameand format must be entered.

It is possible to have both read and computed criteria for asynchronization level, but for a given file there can only beone type of criterion: either READ or COMPUTED.

The synchronization levels must be the entered in order ofsize, starting from the largest (most detailed). When we are ina situation involving n-level synchronization, we are alsonecessarily in a higher level of synchronization.

SL1 - > SL2 - > SL3 - > SL4.

With the concept of synchronization comes that ofnonsynchronization. We can use these concepts to conditionthe processing.

During generation

• Read criteria are generated directly in the program.

• Computed criteria generate paragraphs of processingwhich the user must enter in the program skeleton.


7-24 47 A3 56BB Rev02

BA13 Break (per level 1 to 4)

This screen is used to establish the break level for eachkinematic file defined. This criterion determines a newprocessing sequence.

The break is established at the level of the record:

• READ if they are obtained by reading a record:

either directly

or after concatenating several entries

• COMPUTED if processing must be executed to give thecriterion a value.

If each file's criteria are read, their total size must be input -meaning the sum of the sizes of each entry defined for a file(the criterion will be of the same size for each file).

If the criterion for one of the files must be computed, its nameand format must be entered.

It is possible to have both read and computed criteria for asynchronization level, but for a given file there can only beone type of criterion: either READ or COMPUTED.

The break levels must be the entered in order of size, startingfrom the largest (most detailed). When we are in a situationinvolving level break, we are also necessarily in a higher levelof break.

BR1 -> BR2-> BR3-> BR4.

With the concept of break comes that of non-break. Thesecan be used to put conditions the processing.

During generation

• Read criteria are generated directly in the program.

• Computed criteria generate paragraphs of processingwhich the user must enter in the program skeleton.


47 A3 56BB Rev02 7-25

BA14 Processing sequences

This screen is used to determine the existence or absence ofa processing sequence:

• Initial: it is performed before the first record is read

• Final: it is performed after the last record has been read

• Total: for a given level, it is performed when there is achange in the break level.

You may also request halting of the processing if you havefinished reading the primary file (when synchronizations havebeen defined).

Example:

Breakdown of the processing

We have an address file and we want to know the number ofaddresses per town, then by region, and finally the totalnumber processed.

We must therefore define:

• The Initial processing:

We initialize the 3 counters required

CNT1 per townCNT2 per regionCNT3 total

• Final processing:

This is only executed after the last record has beenprocessed. It enables us to display the total number ofaddresses read, contained in counter CNT3

• Total processing for level 1:

The level-1 break is defined as being the change of town.

Each time the town changes, this processing isexecuted. It consists of displaying the number ofaddresses for the town (counter CNT1), adding CNT1 toCNT2 (regional total), and reinitializing CNT1.


7-26 47 A3 56BB Rev02

• Total processing for level 2:

The level-2 break is defined as being the change ofregion.

Each time the region changes, this processing isexecuted. It consists in displaying the number ofaddresses for the region (counter CNT2), adding CNT2to CNT3 (total counter), and reinitializing CNT2.

Note: When the town change corresponds to the regionchange, the Total processing sequences are chained:Total sequence 1 followed by Total sequence 2.

BA15 Detail processing

This screen is used to define the various processingsequences you wish to apply to the current record.

This processing may be conditioned by:

• The file read (among the 4 kinematic files): if the recordto be processed comes from the file indicated, thesequence is executed.

• the break and synchronization levels

as well as Non-break and Non- synchronization.

The condition for execution of a sequence can be alogical combination of all these factors.

Comments:

• All the "detail" sequences defined are executed in theorder in which they were described

• A given sequence can be referenced several times.

• Their numbers are not necessarily successive.

• The maximum number of sequences which can beexecuted in a batch program is 40.


47 A3 56BB Rev02 7-27

7.5 CODING

Description of the processing:

BA16 Initial processing (label = INI)

BA17 Final processing (label = FIN)

BA18 Total processing, level n (label = TOTn) n = 1 to 4

BA19 Detail processing m (label = DETm) m = 1 to 40

For each processing request defined in forms BA14 and BA15, there is a screen enablingyou to define the processing sequence (8 lines) and, if necessary, give the names of theCOPYs used by the processing.

During generation, we find for each sequence:

SIN-lab . *** description of the processing sequence * ***C0PY copy name (up to 4 times)SIN-lab - F.

BA20 Criteria for selecting a record read.

At the level of each kinematic file defined, it is possible not toprocess certain records.

You must therefore define the condition(s) for selection of arecord.

All the logical operators can be used.

For a condition line, it is possible to link factor 1 and factor 2with the following conditions:

= , > , < , >= , <= , ><

A total of 8 conditions can be defined for a given file. Theseconditions are:

• either independent of the previous one, if no linking term(AND, OR) is used

• or linked to the previous one by a linking term (AND, OR)so that they can be combined.

During generation, these conditions are integrated in thestructure Y <source name>, as they condition whether arecord is taken into account or not, and therefore reading ofthe next record, if necessary.


7-28 47 A3 56BB Rev02

The COBOL phases generated are:

IF factor-1 condition factor-2 [GO -----][AND factor-1 condition factor-2 [GO -----][OR factor-1 condition factor-2 [GO -----] ]

Everything between [] is optional, depending on the label ofthe condition(s).

Example:

1 A = B2 C > D3 AND E < > F4 G <= H5 I >= J6 OR K = L7 AND M < > N8 OR O = P

Generation will yield:

{1} IF A = B GO lab-SINDIA7.

{2} IF C > D {3} AND E NOT = F GO lab-SINDIA7.

{4} IF G < = H GO lab-SINDIA7.

{5} IF I >= J {6} OR K = L { } {7} AND M Not = N {8} OR 0 = FG GO lab-SINDIA7.

BA21 Deletion of a Batch program

This screen is used to display information about the source tobe deleted:

• the comments

• the kinematic files to which they refer

and to confirm (VAL command) or cancel the deletion.

Everything referring to this source will be deleted in the filesSINPRGB, SINRUB, and SINDIC.

BA21 Duplication of a source

This screen form is used to define a new program byintegrally reusing the parameters in a source createdpreviously.


47 A3 56BB Rev02 7-29

The following must therefore be input:

• a new source name

• a new object program name

• the comments

only these 3 parameters can be modified at first. :

BA23 Selection of an entry point

This form is used to access a parameter management phasedirectly

Simply enter SEL in the command field and one of thefollowing codes in the parameter field.

ID

Fl

WS

TB

LK

TC

Cl

CN

RP

TR

DT,t,n

CD

Identification

Files

Working Storage

Tables

Linkage

Common processing

Kinematics

Synchronization

Break

Definition of processing sequences

Description of processing sequences

Selection conditions

Note :n = break level or sequence numbert = type of processing: Initial, Final, Total level n,

Detail, with the sequence number n n and t areoptional


7-30 47 A3 56BB Rev02

7.5.1 Generation

Batch program generation is activated when the parameters regarding the sourceprogram to be generated have been entered. There are several ways to activate it:

• either outside TDS under JCL, by running the procedure

JCL : JFGENPRG EJR GENPRG VL = nom de source.

• or outside TDS under GCL, by calling up a parameter input menu: GFGENPRG.

• or under TDS using the SINDIA7 BATCH function enabling batch jobs to be run underSINLI PR

S IN LIP B S IN P R G B

G E S P R G

S IN W RK B S IN LN K B S IN JC LB S IN S R C B S IN C O DB

optional

Generation takes place in a single lot with several phases.

Construction of a Batch file can be divided into 2 parts:

• Structure named Y < source name >, containing all the COBOL code of the procedurepart managing the kinematics. It is made up of the following elements:

- files (in COPY form)

- Working-Storage (with structure COPYs if necessary)

- Linkage Section (with structure COPYs if necessary)


47 A3 56BB Rev02 7-31

- the chaining of the processing sequences (depending on Breaks andsynchronization)

- source name X (description of processing).

This structure therefore groups everything involved in file management (reading ofrecords and determination of which records to process).

IMPORTANT

The user must never intervene inside this "Y <source name>" programstructure

• The processing skeleton: this is created in SINSRCB with the name "X <source name >" . It contains a set of references (comments, start label, end label) corresponding tothe different processing sequences, and requested during parameter input, as well asthe requested sequences for computing the break or synchronization identifiers.

The user must complete this skeleton by inserting the COBOL code of each processingsequence.

• New structure in the Working Storage section>n:

When you request creation of a Working Storage structure during parameter input, it iscreated in SINWRKB with the name W c source name > .

The file is temporary and optional; it exists only for the time it takes to create thestructure.

• New Linkage Section structure: (same procedure as for the Working Storage)

If you request creation of a new structure, it is created in SINLNKB with the name L csource name > . The file is temporary and optional.

• JCL sequence: the 4 points discussed above indicate that we have createdindependent library members. This JCL enables a name to be assigned to each of thestructures and establishment of links between all the members.

IMPORTANT

The JCL created is internal to the program generation and under nocircumstances should it be modified.

7.5.2 Input of the COBOL code of the processing sequences

Unlike the method implemented for generating a TPR, whose parameters are enteredusing GESTRX, BATCH program generation does not necessitate a generation phaseafter updating with the text editor.

In GENPRG, the structures generated are directly compatible.


7-32 47 A3 56BB Rev02

The programmer job is therefore to use the text editor for inputting the code of theprocessing sequences defined, and compiling the member Y < source name > .

The code must be inserted directly and only in the structure X < source name >, which isthe really the skeleton of the batch program before compilation.

This member only represents processing functions: Initial, Final, Total, Detail and identifiercomputation. It is not therefore the whole batch program, simply the "COPYs" of theprocessing sequences defined as parameters, and which must still be defined by theprogrammer.

Construction of the skeleton X source name is simple. There is a series of paragraphscorresponding to the processing sequences defined by the parameters.

Start-Lab.** Comments entered during definition* of the processing in GESPRG* End-Lab.

The COBOL code must therefore be inserted for each processing sequence between theparagraph start and end labels.

The different types of paragraphs possible are as follows:

1) - SIN-INI - SIN-INI-F

If an INITIAL processing sequence isdeclared.

2) - SIN-FIN - SIN-INI-F

If a FINAL processing sequence is defined.

3) - SlN-TOTn - SlN-TOTn-F

For each TOTAL processing sequencedefined with break level n.

4) - SlN-DETm - SlN-DETm-F

For each DETAIL processing sequencedefined; m is the sequence number enteredin GESPRG (m = 1 to 40).

5) - SlN-RUPn-Fx - SlN-RUPn-Fx-F

For each identifier computation for Breaklevel n (1 to 4) concerning a kinematic file x(1 to 4).

6) - SlN-CNCn-Fx - SlN-CNCn-Fx-F

For each identifier computation for asynchronization level n (1 to 4), concerning akinematic file x (1 to 4).


47 A3 56BB Rev02 7-33

IMPORTANT

Example:

Th e us er m ust n ev er ch ang e the orde r of th e proc es s ing , o r h e ris ks lo sin g the co de w hich h e has ins er te d if the re is re ge neration (after p aram eterm od if ica tions ) .

H e m us t no t jum p from o ne p roce ss ing se qu enc e to ano th er (g ene ra te dp ro ces sin g)or h e risk s loo pin g.

l t is p ossib le , w ith in a g ene ra te d proc es s ing s eq ue nc e, to ca ll a sp ec if icp ro ces sin g p ara grap h us ing PE R FO R M .

It is h ig h ly recom m e nde d to p lace this sp ec if ic p arag ra ph im m e dia te ly afterthe e nd la be l o f the g en erated p roce ss ing pa rag raph to w h ich it re fe rs .

generated SIN-DET 10 * Detail Comments Move 1 to I IF I < 5 PERFROM A10 THRU A1OF ADD 1 T0 I.generated SIN-DET 1 O-F. A10 . DISPLAY "BATCH" A10F.

Th e us er d oe s no t ha v e to m an ag e f ile op en ing a nd c los ing if the m odeo f u se w as e n tered ( the typ e of f ile)

K in em atic f ile read s a re g ene ra te d , a nd the use r m u st add n othin g.H o w ev er , if on e o f th ese 4 f iles is op en ed in m ode U (U p date) , the u se r isresp ons ib le for a ny w r itin g.

Th e us er is en tirely res po ns ib le for an y re ad ing a nd w r iting on the 2 0se co nda ry f ile s .

l f, in a proc es s ing seq ue nc e, the u ser ne ed s a v ar iab le, it m u st be d escr ib edu s ing the W orkin g S to ra ge o r th e Lin ka ge S ection .

Th e v ar iab les used m ust no t ha v e th e prefix S IN .

F or p ro ce ss in g cond itio ne d by syn chro niz ation s, th e us er m us t w o rk o n th esynchroniz ed rec ords , w h ich m e ans th a t:


7-34 47 A3 56BB Rev02

IMPORTANT (con td.)

.

.

.

F or p ro ce ss in g cond itio ne d by the b re ak s ( to ta l p ro ce ssin g at b reak- lev e l n ),the u ser on ly ha s on e re co rd a v aila b le - the rec ord w he re the b reak iso bse rv ed , m ean ing the f irs t for the n ew ide ntif ier . C are sh ould be tak en tosa v e th e data ab ou t the p rev ious iden ti fier if th e lev e l's to ta l p ro ce ss in g isg o ing to us e it.

I f the u se r m a ke s m od if ica tio ns to the p roce ss ing pa ram eters , he h as to"reg en era te" the p ro gram .

Th e struc tu re Y < so urce n am e > w il l b e com p le te ly re ge nerated . Thesk ele to n X < s ou rc e na m e> w ill s im p ly b e m od if ied b y com pa ris on o f thep ro ces sin g de fine d by the p aram eters an d th e lab els in th e pa rag rap ha lre ad y w rit ten.

If th e pa ra grap h is s ti ll refe ren ced, all th e co de u p to the n ex t p arag rap h isleft ( fro m the s ta rt o f a g en erated p ara grap h to th e star t of the ne xt).

If th e pa ra grap h is n o long er re fe re nc ed , th e code is dele te d, from th e sta r t o f the p arag ra ph up to the s ta rt of th e nex t.

-

-

Batch program source name EXAMPLE 1.

Skeleton name X EXAMPLE 1.

When this program's parameters were entered, we requested the following sequences:

• Initial• Final• Detail processing 2• Detail processing 5• Computation of break identifier in level 2 on file 3.

After the first generation

The user enters the COBOL code corresponding to the processing (paragraphs A, B, C,D, E, F, G).

He modifies the paragraphs entered

• no final sequence• no Detail processing 5

But he wants

• total processing on level-1 break• Computation of level-1 break identifier on file 2.


47 A3 56BB Rev02 7-35

The 2nd generation enables all the code input for the unchanged processing to be kept.The skeleton is modified by comparison of the processing parameters defined and thestart-labels in the existing skeleton. This is why, since detail processing 2 still exists,everything between SIN-DET2 and SIN- DET5 (generated label) is kept.

X EXAMPLE 1

1st Generation

SIN-INI. * Init. Comment A SIN-INI-F SIN-FIN. * End Comment . B SIN-FIN-F SIN-DET 2.

* Detail processing 2. C PERFORM C2 THRU C2F. D

SIN-DET 2-F C2 E C2F. SIN-DET 5. * Detail processing 5. F SIN-DET5-F. SIN-RUP2-F3. * Break 2 file 3 * Identifier computation G SIN-RUP1-F2-F.

2nd Generationafter parameter modification

SIN-INI. Retrieve unchanged SIN-INI-F SIN-TOT 1 * TOTAL processing Break 1 M SIN-TOT 1-F SIN-DET 2.

Retrieve unchanged

C2F SIN-RUP1-F2 * Identifier computation* Break 1 file 2 I SIN-RUP1-F2-F. SIN-RUP2-F3. Retrieve unchanged

SIN-RUP2-F3-F.


7-36 47 A3 56BB Rev02

47 A3 56BB Rev02 8-1

8. Optimizing the GCOS 7 Environment

8.1 ANALYZING A TDS SESSION

The performance of the transactional application must be followed as it runs so that anydegradation can be detected and remedied.

There are two ways to follow up performance:

• the job occurrence report (JOR)

• statistics provided by the TDS monitor.

8.1.1 Analyzing the JOR

On the following pages you will find an excerpt from a JOR with comment numbers.


8-2 47 A3 56BB Rev02

Optimizing the GCOS 7 Environment

47 A3 56BB Rev02 8-3


8-4 47 A3 56BB Rev02


47 A3 56BB Rev02 8-5


8-6 47 A3 56BB Rev02


47 A3 56BB Rev02 8-7

(A) Loading transactions in SMLIB (STEP1)

(B) Running of TDS (STEP2)

(1) Names of the shared modules (SM) used. The default SINDIA7 JCL uses the SMnamed TPR. If there is an overflow of the number of inputs available in this SM(256), TPR1, then TPR2 will be used.

In the example given, only the SM named TPR has been used.

(2) XPRTY gives CPU dispatching priority. It must be set to zero, which is the highestpriority.

(2.1) The message MT67 SWAP FILE TOO SMALL indicates that the swap file internal toTDS is too small for the desired number of terminal operators (72, in the example):the number of cylinders (evaluated from the information provided when the TDS wasgenerated) is too small compared with the number of terminal operators.

The size of this file is calculated as follows:

< Size of one input> X < number of entries >+ 100 x number of controlled files+ size of longest TRANSACTION-STORAGE+ the sum of the sizes of primary keys of indexed sequential files.

One input equals:

(MESSAGE LENGTH + 800) rounded to the next higher Kbyte

The number of entries is calculated:

< number of terminal operators > X 2+ < number of active BREAK transactions > X 2

(3) The message states that the Ifn files BLIB,BINLIB1,BINLINB2,BINLIB3 are notassigned in the JBL. They are not used in the example.

(4) Before Journal Allocation

Message FP04 specifies the initial allocation size and the volume on which thejournal was allocated. The internal and external file names (ifn and efn) are alsoprovided.

Message JL00 specifies the maximum size attained, and message JL06 indicateshow many extensions were necessary (successful or not) to attain it.

The before journal must be located on a disk which has a low access load otherwise.

(5) Statistic concerning use of the UFAS EXTENDED access method for each filechecked by TDS. (2 lines per IFN and 2 lines per EFN).


8-8 47 A3 56BB Rev02

(6) Using the Before Journal

Message JL07 provides statistics on Before Journal use by specifying the number ofrollbacks. If there is a conflict of resources between several holders, the generalizedaccess control facility (GAC) may decide to reset a commitment unit to a previousstable state. This means that updates already made to Cls will have to be canceledby using the data stored in the Before Journal. This operation is called a rollback.

Statistics give the following information (in this order):

• the number of commitment units involved in a rollback operation due to conflict.

• the number of TPRs involved in an abort and a rollback. This corresponds tolong waits,

• the 3rd figure concerns the use of IDS2 data bases and is not described here.

The sum of these figures gives the number of conflicts which have been processedby the Before Journal use.

Obviously, the lower the number the better.

(7) Statistics concerning file concurrence (GAC)

GAC1 messages give statistics concerning GAC activity file by file:

• the number of conflicts. If the commitment is waiting for a Cl to be released, thisnumber is increased by 1 for this file. This counter lets you see the conflict rateper file. The lower this number is, the better. To decrease the number ofconflicts, check whether or not this file can be accessed in static read mode(SUPPRESS CONCURRENT ACCESS CONTROL) or, if this is not possible, inSHARED READ mode.

• the number of DEADLOCKs on these files. A deadlock leads to a TPR abort(and therefore to a rollback).This number must be as low as possible.

To lower it, check whether or not transactions keep resources too long and dointermediate commitments.

(8) Global concurrence statistics (GAC)

The GAC2 message specifies the queuing count resulting from concurrence. Whena conflict can only be resolved by aborting the TPR and restart is unsuccessful, GACplaces requests in a queue, and increments. This counter by one. The queuing countis therefore a global counter for the number of concurrence conflicts that could onlybe resolved by extreme methods: request queueing and serialization of thesequeued requests which are processed one after another.

From the terminal operator's point of view, serialization increases response time.


47 A3 56BB Rev02 8-9

(9) Global UFAS statistics

This information is an aid for dimensioning the UFAS buffer pool.

UFAS allocates its buffers in the pool which, from the point of view of virtual memorymanagement, is locked space. If this pool is not big enough, UFAS temporarilyallocates buffers in the unlocked portion of memory (swappable memory). TheUNLOCK buffer counter specifies the number of these operations. This numbershould be as close to zero as possible, otherwise the size of the pool (POOLSIZE)must be increased.

The 2nd counter in message DUF09 specifies the number of CREATE BUFFERoperations in the pool.

A rate of 1 8UFFER CREATE per 100 10 CONNECTS for all useable files isacceptable.

A higher rate means that the sizes of the accessed file Cls are too heterogeneous. Inwhich case, these sizes must be made more consistent.

(10) Number of inputs/outputs in BACKING STORE

Optimizing access to these system files goes beyond the scope of this manual. Referto the SYSTEM MANAGEMENT GUIDE and the SYSTEM OPERATOR GUIDE.

Note that you can configure the contents of these input/output files in order to obtaina better input/output distribution along several axes.

(11) Before Journal Activity

The displayed number of inputs/outputs includes the preformatting of the BeforeJournal and its effective use.

You should therefore count one per modified Cl in a commitment unit, plus one foreach commitment itself.


8-10 47 A3 56BB Rev02

(12) TDS File Activity

After a formatting operation when initializing the TDS, each TPR results in 2inputs/outputs for this file.

Do not locate it along the same axis as the Before Journal.Use the multivolumeSWAP file facility in the event of saturation due to the SWAP file.

(13) User File Activity

Similar to point (7).

The ratio of S REUSEs to S lO CONNECTs must be as high as possible.

The S REUSE/S O CONNECT to POOLSIZE curve looks like this:

REUSECONNECT

POOLSIZE

The limit values are dependent on the type of application and how it wasprogrammed, i.e:

• random access only

• random access, then "long" sequential scanning.

The POOLSIZE (and therefore the SIZE allocated to the STEP) should be increasedknowing that beyond a certain threshold, the gain will be low.


47 A3 56BB Rev02 8-11

(14) Number of missing segments The number of segment errors is classified under twoheadings:

• number of missing segments for the TDS application (PROG MISSINGSEGTS),

• number of missing system segments called by the TDS application (SYSMISSING SEGTS).

The "thumb rule" to be used is as follows:

• a add to these two figures the number of missing segments specified in theJOR's BTNS (or FNPS) to obtain a number F of missing segments,

• The ratio of F per number of exchanges must be less than or equal to 1.

There may be two reasons for too high a ratio:

• poor segmenting;

• insufficient memory size.

To improve segmenting, follow these suggestions:

• avoid TPRs which are too large (see below: mono-TPR and multi-TPRtransactions),

• replace the CALLs by COPYs in the programming,

• compile using the CODAPEND option to attach the link segment to the 1st TPRcode segment.

• compile using the PSEGMAX = 64 and DSEGMAX = 64 options,

• compile using the NDEBUG option.

To find out the optimum memory size (SIZE), plot the number of missing segmentsversus SIZE on a curve using the MAXMEM option according to therecommendations in the SYSTEM MANAGEMENT GUIDE.

This is a description of what the SINDIA7 programmer analyst may do. Furthermore(refer to the SYSTEM MANAGEMENT GUIDE), you can use the memory preloadfacility (PMM) for the system functions used and for the most frequently used TPRs.

Note that manipulating memory size lets you isolate TDS from the point of view ofthe memory and have it unaffected by the other activities. Reminder: manipulatingmemory size is meaningful only if main memory is larger that 4 mb.

(15) CPU Elapsed Time

Set up a ratio between CPU elapsed time and the number of TPRs. This ratio mustbe monitored and if it varies too much, you should look for the causes.

As a general rule, this ratio should not vary too much from one session to another.

(16) TDS Session Duration

The duration itself is not very significant.


8-12 47 A3 56BB Rev02

Observe and monitor the following ratio:

< number of TDS exchanges > / < session duration >

The average number of TDS exchanges per second is a characteristic of thetransactional application and CPU power.

(17) The LOGON TPR is displayed with the user name, the terminal name and the type ofterminal logging on.

8.1.2 Analyzing TDS Statistics

Below is a report on general TDS statistics followed by comments.

USER-NAME LAST-TERM TX-COUNT-TPR-COUNT

(1) MOREAU DP78V890 8 11

****** GENERAL STATISTICS ****** TDSNAME ................................... : TDSN(2) # OF TRANSACTIONS ......................... : 10(3) # OF USED TPR ............................. : 16(4) # OF EXCHANGES ............................ : 13(5) # OF COMMITMENT UNITS ..................... : 13(6) TOTAL TPR ELAPSE .......................... : 16165(7) TOTAL TPR CPU ............................. : 365(8) # OF NON-CONCURRENCE CONFLITS ............. : 0(9) # OF SERIALIZATIONS ....................... : 0

****** ABORT STATISTICS ******(10) # OF ABORTED TRANSACTIONS ................. : 0(11) # OF ABORTED TPR .......................... : 0

(12) # OF BUFFER OVERFLOWS ..................... : 0(13) # OF DEADLOCKS ............................ : 0(14) # OF LOCKED PAGE TABLE OVERFLOWS .......... : 0(15) DIRTY READ ABORTS ......................... : 0(16) # OF LONG WAIT ............................ : 0(17) # OF PSEUDO-BUFFERS ....................... : 0

(1) The two numbers on this line specify:

• the number of user transactions (TX-COUNT),

• the number of corresponding TPRs,

• for the sessions which have been terminated normally (using BYE). Transactionactivity in master mode (M...) is not included.

(2) Total number of transactions (user and master).

(3) Total number of TPRs (user and master, aborted or not).


47 A3 56BB Rev02 8-13

(4) Total number of exchanges correctly terminated ((3)/(4)).

Suggestion: the ratio of the number of TPRs to the number of exchanges must beless than 3 and as close to 1 as possible.

(5) Number of correctly terminated commitments.

Suggestion: the ratio of the number of commitments to the number of exchanges((5)/(4)) must be less than 1.5 and close to 1 if possible.

(If too many TDS exchanges are done without commitments, more resources areblocked for a longer period of time and therefore the probability of blocking is higher).

(6) Total TPR time elapsed (in milliseconds). Calculate the ratio of total elapsed time tototal number of TPRs ((6)/(3)).

Suggestion: monitor changes in this ratio. An increase may mean:

• there is an increase in the number of inputs/outputs per TPR,

• there are too many Cls being locked causing waits.

(7) Total TPR CPU time (in milliseconds)

Calculate the ratio of CPU time to the total number of TPRs ((7)/(3)).

Suggestion: monitor changes in this ratio. It depends on CPU performance.

Do not do processing which is costly in CPU time in TPRs: for example, do not call aSORT from TPRs...

(8) Number of conflicts due to the use of the "NON CONCURRENT WITH" clause.

This counter lets you evaluate the use of this clause.

Note: master transactions are not executed concurrently with the others.

Suggestion: insofar as possible, let GAC handle conflicts. Transactional

(9) Number of serializations

This counter specifies how many times a TPR had to be run alone.

To decrease this number:

• increase the number of locked Cls (NUMBER OF LOCKED PAGES clause)and the POOLSIZE,

• if possible, use the exclusive read mode or suppress deferred update mode(SUPPRESS DEFERRED UPDATE clause).

(10) Number of aborted transactions

(Programming error, BREAK at the terminal, line loss, etc.).

(11) Number of aborted TPRs

Check the causes given by the return code in the TDS job occurrence report.


8-14 47 A3 56BB Rev02

ENQUE : Abort due to a GAC refusal when working in serializationmode.

LONGWAIT : See remark (17).

ITMNAV : The " SUPPRESS BEFORE JOURNAL" clause or the"SUPPRESS AFTER JOURNAL" clause was used for atransaction which was supposed to access certain filesonly in read mode.

Due to a programming error, the transaction attempted toaccess one of these files in write mode.

WDNAW : The "SUPPRESS DEFERRED UPDATE" clause was usedfor a transaction.

Due to a programming error, the transaction attempted awrite operation.

DEADLOCK : See remark (13)

BUFNBOV : See remark (12)

TABOV : See remark (15)

(12) Number of TPR aborts due to buffer overflows

When using "DEFERRED UPDATE", the buffer pool was in an overflow condition(the amount of requests was greater than the value given of the RESERVE n AREASof the TDS generation).

As a consequence, the commitment unit was aborted, the counter (12) wasincremented by 1 and the " DEFERRED UPDATE" mechanism dropped to relaunchthe commitment unit.

If the Before Journal is not assigned, there is no possible restart: the transaction isaborted. If this is not the case, the commitment unit is restarted and uses the BeforeJournal only.

If again, there is an overflow of the buffer pool, there is a new abort of thecommitment unit with incrementation of the counter (12), and restart with the BeforeJournal, and serialization.

Suggestion:

• adjust the value "n" of the TDS generation (RESERVE n AREAS) and increasePOOLSIZE accordingly.

• if this is not possible, search for transactions with many updates and whichsimultaneously refer to a great number of Cl's and, for these transactions, usethe "SUPPRESS DEFERRED UPDATES" clause of the transaction section.

(13) Number of commitment units aborted due to deadlocks

This counter is characteristic of the attempts of simultaneous updates of the sameCl's.


47 A3 56BB Rev02 8-15

Each time there is a deadlock, the concurrent access mechanism chooses thecommitment unit to abort (to break the deadlock) and hence to allow the execution ofthe other commitment units. The aborted commitment unit is automaticallyrelaunched after rollback.

When the updates mean there is a high chance of conflict, it is better forperformance reasons to use exclusive read, which makes the others wait.

(14) Number of aborts due to an underestimate of the number of locked pages in TDS.

• increase the number provided in the clause:

NUMBER OF LOCKED PAGES

• Check the values used when configuring the system (CONFIG: GAC commandLOCKSIZE parameter).

(15) Number of statistical reads causing a TPR abort

This situation is only possible for the IDS2 data bases.

(16) Number of TPRs aborted due to a wait having exceeded the LONGWAIT limit.

To prevent blocking, TDS aborts the TPRs on long wait for resources (the holderchains from one TPR to another while keeping resources and not releasing them).

Reducing the LONGWAIT duration increases the number of aborted TPRs, but canimprove overall throughput. Also check the number of locked pages (15).

(17) Number of PSEUDO-BUFFERS

These are volatile buffers created in swappable memory due to lack of space in thepool.

Increase the pool size and (if necessary) the memory size of the TDS step.


8-16 47 A3 56BB Rev02

8.2 OPTIMIZING FILES HANDLED BY UFAS

8.2.1 Choice of CISIZE

The ratio CISIZE -8 is the blocking factor. You should use it within the following AFCSIZE + 4limits:

10 < CISIZE - 8 < 20 RECSIZE + 4

If there are very volatile secondary indexes, use CISIZE < 10.

Note: 1) There must be at least 2 records per Cl.

2) The CI size must be a multiple of 512 octets

8.2.2 Choice of INCRSIZE

Use a low unit value: record, Cl, track, cylinder or blcok.

8.2.3 Evaluating the pool size (POOLSIZE in command JCL: SIZE)

Estimate as follows:

POOLSIZE = CISIZE x ((f x simu) + (u x simu) + simu + ni)

u : average number of Cls updated by DEFERRED UPDATE)ni : total number of indexed sequential UFAS filesf : average number of files usedsimu : TDS simultaneity level

If you underestimate the POOLSIZE, there will be too many pseudo-buffers created inswappable memory.

8.2.4 Relation between CISIZE and the type of disk

Refer to the UFAS User's Guide (47 A2 04UF) for further information.


47 A3 56BB Rev02 8-17

8.2.5 CREATE-FILE (interactive) utility

The CREATE-FILE utility (REPORT command) specifies the memory requirements,number of index levels, etc.

It can be used to create a file using the allocation parameters of another file as a model(eg. CREATE-FILE ... LIKE ...), and to modify those parameters (eg. size) if desired.Systematically using model files enables you to maintain consistent sizes and allocationparameters.

8.3 "FOR INQUIRY" TRANSACTIONS

When a transaction is used for inquiry purposes, and in the event of a conflict thetransaction can be aborted, it is a good idea to declare it "FOR INQUIRY" whengenerating it. This results in a considerable gain in performance (no context to be saved).


8-18 47 A3 56BB Rev02

8.4 "FOR DEBUG" TRANSACTIONS

This option lets you implement a transaction with all the functions of a normal transactionexcept for write operations which are not done.

This facility is ideal for debugging without risk to actual files.

Note: do not forget to remove the "FOR DEBUG" clause when you want to actually runa transaction.

8.5 SHAREABILITY OF MONITORED FILES

8.5.1 Non concurrence

First of all, if you do not want to implement sharing, you can declare the transaction nonconcurrent with itself and the other transactions referring to this file when generating it.You must be aware of the limits involved in doing this. This serializes requests andtherefore decreases the overall throughput of the TDS.

It would be better to use generalized concurrent access which offers different levels ofaccess.

8.5.2 Reminder concerning locks used by GAC

8.5.2.1 Shared read

• Several "users" can access the same Cl in shared read or statistical read modes.

• Any exclusive read or write request on a Cl being shared is placed in the queue.

• Implementation: "SHARED READ FOR ..." clause in the TDS generation messageclause.


47 A3 56BB Rev02 8-19

8.5.2.2 Exclusive read

The Cl can be accessed in read mode by the requestor.

• Any request for statistics read on the same Cl already in shared read mode isaccepted.

• Any other request is placed in the queue.

• This option is the default value of the message clause: it must therefore be evaluated ifthe shared read or statistics read is not possible.

8.5.2.3 Statistical read

• All Cls can be accessed.

• All types of concurrent access are authorized.

• Risk: reading inconsistent data (dirty read).

• Constraint: cannot be followed by a write for the same file.

• Implementation: " SUPPRESS CONCURRENT ACCESS CONTROL FOR . . . " clause.

8.5.2.4 Write

• The Cl is locked.

• All other types of concurrent access are forbidden (except statistical read).


8-20 47 A3 56BB Rev02

8.5.2.5 Recap

CL Holder Lock

Requestor Statisticalread

Sharedread

ExclusiveR or W

Statisticalread NO QUEUE

Sharedread NO QUEUE QUEUE

Exclusiveread NO QUEUE QUEUE

Write NO QUEUE QUEUE

8.5.3 GAC Operating Parameters

When configuring the system, the following parameters come into play (CONFIG utility):

LONGWAIT maximum amount of time a TDS user can wait for the releaseof a Cl (default value is 60 seconds), maximum value: 300sec.

Too long a LONGWAIT may lead to additional conflicts, tooshort a LONGWAIT may lead to too many aborts.

LOCKSIZE Size of the locked Cl table. This size varies from 5 to 319 K,enabling 250 to 16000 inputs.

Estimating the value:

• Count 1 input per GAC user (1 per step not TDS; forTDS, the number of active commitment units countwhich can be higher than the simulation level if theUNMAPPING facility is used).

• Count 1 entry per application using GAC.

• Count 2 entry per file checked by GAC.

• Count 1 entry per user and multiply the number of GACusers by the number of files checked by GAC.

• For each TDS, count the number of locked pages.

• Take the sum of all these numbers to obtain theestimated number of entries, then

multiply by 20 (input size)


47 A3 56BB Rev02 8-21

divide by 1000 (size or kbytes)add 15%(safety)

to obtain an estimated LOCKSIZE value.

NBLOCKID Defines the maximum number of GAC users simultaneouslyactive (from 100, to 4095 default value).

8.5.4 Using the Table of Locked Pages

The "NUMBER OF LOCKED PAGES IS" clause in the transaction section specifies thenumber of Cls that the transaction can lock. if you exceed this number, the TPR is abortedby GAC and restarted in non concurrent mode. This counter acts as a barrier againstprogramming errors. It should be carefully estimated: too small a number will causerestarts in non concurrent mode (serialization).

The "MAXIMUM NUMBER OF LOCKED PAGES" clause acts as an overall barrier forTDS. The transaction having caused the error is aborted.

TDS statistics can be used to monitor the number of locked page table overflows.

8.5.5 Case Study

8.5.5.1 Entering n record codes and modifying

You may find it useful to have a transaction in which the end user enters "n" (large) recordcodes and makes modifications all at once. The corresponding processing consists inupdating the files after the necessary checks are performed.

The limits of such an approach are that if the number "n" of records is large, theprocessing operation associated with the exchange generates a high number ofinputs/outputs, hence a higher number of Cl locking, a higher probability of conflicts andan increased response time.

It is better to avoid this type of exchange. But you should not go overboard the other wayeither and have too little data to be entered by the terminal operator at each exchange assparse forms potentially increase the frequency of system calls in terms of exchanges.The processing of an exchange request is optimized by TDS and SINDIA7, buteconomically contribute nothing in terms of processing: you should not add to generatingsuperfluous exchanges by using too sparse forms.

The compromise resides in the type of processing associated with the exchange: theexchange should remain simple and direct. You should not do heavy processing in theprocessing operation associated with an exchange.


8-22 47 A3 56BB Rev02

8.5.5.2 Common read/update problem

In a great number of applications, the dialog is as follows (the examples of dialogs whichfollow are only part of the SINDIA7 analysis sheet):

Exch. Level Description

1 O Enter the references of the records

T Read the files and prepare the display

2 O Modify the values you want to.

T Update the files.

If you do not pay attention, the default values (IMPLICIT COMMITMENT) requested bySINDIA7 cause validation when chaining from exchange 1 to exchange 2: the Cls readare returned and can be modified by other accesses.

The remedy consists of switching to explicit validation mode, in other words of requestingthat the Cls read remain blocked when chaining from exchange 1 to exchange 2. To dothis, you must assign the VALUE 0 to the SINLOP variable:

MOVE 0 TO SINLOP

In processing operation PSIN1 in exchange 1. This way, the commitment unit is extendedto exchange 2. The end user works on a consistent set of data when entering themodifications in exchange 2.

This method considerably increases the time during which resources are blocked sinceyou have to add to the processing time, the time it takes the terminal operator to think andenter data, which is expressed in minutes. The probability of an access conflict thereforeincreases. The other users are waiting and the Cl go into the GAC LONGWAITmechanism.

This type of solution is therefore not favorable for a good response time.


47 A3 56BB Rev02 8-23

To ensure a good response time, it is better to operate as follows in such a context:


1 O Enter the references for the records.

T - Read the records- Save the records as well as the recordreferences in transaction-storage- Prepare the display

2 O Modify the values you want to

- Reread the records- Compare with the records saved in transaction-storage- If they are equal: rewrite them; otherwiseprocess as an error.

The processing operation in exchange 1 saves the records read as well as theirreferences in transaction-storage (which is an area saved between two exchanges) andreleases the resources.

The processing operation in exchange 2 rereads the same records (owing to thereferences kept in transaction-storage) and compares them with the saved records. If theyare the same, this proves that between exchange 1 and 2 they were not modified by anyone else accessing them and can therefore now be modified. If they are not equal, therecords have been modified in the meantime and you must process the error.

The number of logical inputs/outputs are doubled, but normally the pool mechanismshould have a favorable effect.

The error processing operation could request the end user to start over again withexchange 1, but this would hardly be a satisfactory solution for the end user or as far asconcerns the potential risk of entering an endless loop if there is concurrence amongseveral other users.

Another processing operation, for recovery, in this case consists in:

• keeping the resources committed (the reread Cls)

MOVE 0 TO SINLO

• chaining, for example, back to the same exchange while redisplaying the values of thecommitted records,

• or chaining to another exchange which displays the values of the consigned recordsand the data already entered in exchange 2 for validation or update by the end user(this may prevent the end user from having to re-enter data).


8-24 47 A3 56BB Rev02

This type of processing prevents the risk of loops. Globally, processing doesn't enter theGAC LONGWAIT mechanism unless there is a conflict resulting in a modification ofrecords.

If the sum of record sizes becomes too large to the point of penalizing the operation by :

• too large a transaction-storage

• too many MOVEs,

You can use a stored locking tag in the files themselves. This works as follows:


1 O Enter the references for the records.

T - Read- If record tagged: then recovery processing 1- If all the records are untagged: tag them (withthe terminal operator's name, for example) andrewrite them.

2 O Modify the values you want to

- Read- If same tag: then update- If tag different: then recoveryprocessing 2.

8.5.5.3 Problem of data entry

This point has already been covered in the description of indirect exchanges at the end ofsection 2. Abstract

Technical publication remarks form

Title : DPS7000/XTA NOVASCALE 7000 SINDIA7 Programmer's Guide

Reference Nº : 47 A3 56BB 02 Date: March 1995

ERRORS IN PUBLICATION

SUGGESTIONS FOR IMPROVEMENT TO PUBLICATION

Your comments will be promptly investigated by qualified technical personnel and action will be taken as required.If you require a written reply, please include your complete mailing address below.

NAME : Date :

COMPANY :

ADDRESS :

Please give this technical publication remarks form to your BULL representative or mail to:

Bull - Documentation Dept.

1 Rue de ProvenceBP 20838432 ECHIROLLES [email protected]

Technical publications ordering form

To order additional publications, please fill in a copy of this form and send it via mail to:

BULL CEDOC357 AVENUE PATTONB.P.2084549008 ANGERS CEDEX 01FRANCE

Phone: +33 (0) 2 41 73 72 66FAX: +33 (0) 2 41 73 70 66E-Mail: [email protected]

CEDOC Reference # Designation Qty

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

[ _ _ ] : The latest revision will be provided if no revision number is given.

NAME: Date:

COMPANY:

ADDRESS:

PHONE: FAX:

E-MAIL:

For Bull Subsidiaries:

Identification:

For Bull Affiliated Customers:

Customer Code:

For Bull Internal Customers:

Budgetary Section:

For Others: Please ask your Bull representative.

BULL CEDOC

357 AVENUE PATTON

B.P.20845

49008 ANGERS CEDEX 01

FRANCE

47 A3 56BB 02REFERENCE

Documents

SINDIA7 Programmer's Guide - Atossupport.bull.com/ols/product/system/gcos7/gcos7-com/g7-dps7000/doc-com/... · 47 A3 56BB Rev02 iii Introduction The purpose of this manual is to provide