DEVELOPMENT 0M DYNAMIC SiMULATiON . ‘
MODEL FOR PLANgNiNG PHYSICAL msrmaunon SYSTEMS:
FORMULATION? OF THE COMPUTER MODEL- '

Thesis for the Degree of th D.
M ICHJGAN STATE UNIVERSITY
EDWARD JOSEPH MARJEN
1970

 

 
 
    

1‘3 LIBRARY

1 Michigan $333”
Univcmty

HI» 3135!

This is to certify that the

thesis entitled
13mm OF A DYNAMIC SIMULATION MODEL

FOR PLANNING PHISICAL DISTRIBUTION SYSTEMS:

FOIMUIATION OF THE COMPUTER MODEL
presented by

Edward J onph Marion

has been accepted towards fulfillment
of the requirements for

PhD. degree in M.

 

Mimi/fat find?
Datwo

0-7639

 

 

 

ABSTRACT

DEVELOPMENT OF A DYNAMIC SIMULATION MODEL FOR
PLANNING PHYSICAL DISTRIBUTION SYSTEMS:
FORMULATION OF THE COMPUTER MODEL

BY

Edward Joseph Marien

To provide consumers with a wide assortment of goods
at the right time, in the right place and at the highest
profit potential, managers have increasingly viewed their
product distribution systems on an integrative basis.

Total integrated costs of transportation, warehousing,
holding and handling inventories, and communications can
be balanced against requirements of consumers for fast and
consistent service.

To achieve an effective and efficient balance between
cost and customer service, product or physical distribution
management is responsible for designing and administering
systems to control finished goods flow and, in some cases,
the flow of raw materials. The problem is how to achieve
the correct balance in a changing business environment.

Given the above general class of problem, a specific
need exists for the development of improved planning models

to aid firms in the design of total physical distribution

Edward Joseph Marien

systems. Such a planning model should be capable of assist—
ing managers to achieve their objectives by determining the
best points in time to implement physical distribution sys-
tem modifications.

The overall objective of an ongoing research project
at the Graduate School of Business, Michigan State Univer—
sity, is to provide such a physical distribution planning
model. The model has been titled Long-Range Environmental
Planning Simulator (LREPS). The research is being con-
ducted by faculty and doctoral students. This dissertation
deals with the computerization of the model on the Control
Data Corporation 6500 computer using primarily the GASP IIA
simulation language and FORTRAN IV.

In formulating the computerized model, an overall
approach was required. This approach is discussed in the
Methodology Section of Chapter I. Various programming and
systems techniques also had to be reviewed for their appli-
cability in the computerization process. These techniques,
such as the use of Monte Carlo selection, pseudo-random
number generation and statistical estimation procedures,
are discussed as the need arises.

The result of the activities associated with this
dissertation is an Operational computer model. Information
systems concepts were initially utilized to segregate the
activities of the computer model into supporting data,
operating and report generator systems. In relation to

these systems, a total data base of information was

 

Edward Joseph Marien

defined. Data base variables were assigned mnemonics and
dimensions.

After developing preliminary specifications of the
computer model's subprograms and data base of information,
the GASP IIA simulation language was selected for pre-
dominantly implementing the model's operating system. A
set of criteria was developed for language selection.
FORTRAN IV and the CDC 6500 assembly programming languages
are used on a supportive basis.

In programming the activities of the mathematical
model, basic building-block subprograms facilitated the
overall development of the computer model. These basic
building blocks are organized and discussed in relation
to the four major subsystems of the computer model. The
four subsystems are: (l) the Demand and Environment
Subsystem for generating and allocating customer demand,
(2) the Operations Subsystem for processing simulated
customer orders through the physical distribution system
configuration being tested, (3) the Measurement Subsystem
for developing the criteria for evaluating the system con-
figuration and (4) the Monitor and Control Subsystem for
supervising and controlling the Operation of the computer
simulation model. In implementing these subsystems on
the computer, magnetic tape, punched cards and listings
are the primary means of model input and output.

The computer model is presently dependent upon MSU's

large-scale CDC 6500 computer operating system. The

Edward Joseph Marien

conversion of the model to another computer operating system
would be very difficult unless a sophisticated FORTRAN com-
piler that would include EXTENDED FORTRAN routines for tape
buffering, shifting and logical instructions plus large
amounts of computer memory were available. Packed computer
words of memory, which are sixty-bit words on the CDC 6500
and which, in many cases, contain up to fifty pieces of
information per cOmputer word, make the possible conversion
process even more difficult.

The operating system of the present computer model
requires a little less than thirty-two thousand decimal,
computer words of memory. Of this required amount of com-
puter memory, the data base of information occupies seven-
teen thousand two hundred words. The execution time is
primarily a function of a firm's sales dollar forecast and
average sales dollars per customer order. Considering the
consumer-oriented firms who might use LREPS, the computer
run times per maximum ten-year simulation cycle might be
unreasonable if they have large sales forecasts and small
customer orders.

Preliminary validation of model results for one
year's sales history plus initial, experimental use of
the model for assisting the management of the project's
industrial research supporter indicate the model is

sound and reliable.

DEVELOPMENT OF A DYNAMIC SIMULATION MODEL FOR
PLANNING PHYSICAL DISTRIBUTION SYSTEMS:

FORMULATION OF THE COMPUTER MODEL

BY

Edward Joseph Marien

A THESIS

Submitted to
Michigan State University
in partial fulfillment of the requirements
for the degree of

DOCTOR OF PHILOSOPHY
Department of Marketing and Transportation

1970

,9.)

CK“

@ COpyright by

EDWARD JOSEPH MARIEN

1971

To my lovely wife, Janet

ii

ACKNOWLEDGEMENTS

Since a Michigan State University research team
deveIOped LREPS, acknowledgements are given to team
members Dr. Donald J. Bowersox, our faculty director,
and doctoral candidates, 0. K. Helferich, R. T. Rogers,
M. L. Lawrence, V. K. Prasad, P. Gilmour and F. W. Morgan, Jr.
They assisted not only in conceptualizing the alterna-
tive methods for accomplishing certain computer tasks
but also in working out the details.

The Michigan State University Computer Laboratory
was a very helpful source of information and assistance
in the development of the various procedures concerning
the use of their available computer operating systems.

I am also particularly grateful to Dr. Charles F.
Wrigley, Director of the Computer Institute of Social
Science Research, who provided a large source of pro-
gramming personnel from which part of the LREPS pool of
programmers was drawn.

The industrial research supporter must be acknowl-
edged for his kind consideration and assistance. Much
of the data for the model was prepared on their computer

systems which alleviated much work at MSU. They also

iii

greatly assisted in conceptualizing and implementing the
system model.

My doctoral committee was composed of Dr. Donald A.
Taylor, Chairman of the Department of Marketing and
Transportation at MSU, Dr. Thomas J. Manetsch, Associate
Professor of Electrical Engineering and System Science at
MSU, and Dr. Donald J. Bowersox, Profeséor of Marketing
and Transportation at MSU, who was the chairman of my
committee. Dr. Bowersox must also be particularly
acknowledged for his assistance in the development of my
dissertation. Being fairly strong in the use of computers
and developing a deeper understanding of physical distri-
bution concepts, I relied heavily upon his guidance in
designing the universal aspects of the computer model.

Mrs. Ann Brown and Mrs. Irene Orr must be thanked
for typing and preparing the dissertation in final form.
Their knowledge of the rules and guidelines for disserta-
tion preparation made my task much easier.

My wife Janet must besincerely thanked for typing
nmny rough drafts of this dissertation, spending many
lonely hours while I was writing plus giving me the

incentive to persevere to its completion.

iv

 

Ill‘d I...

a

TABLE OF CONTENTS

DEDICATION O O O O O O O O O O 0
ACKNOWLEDGEMENTS . . . . . . . . .
LIST OF TABLES . . . . . . . . . .
LIST OF FIGUES O O O O O O O O 0
LIST OF APPENDICES O O O O O O O 0
Chapter

I. INTRODUCTION . . . . . . . .
Scape of the Research . . . .
Situational Analysis . . . .
System Identification . . .

Detailed Problem Statement and
Researchable Questions . . .

Methodology . . . .
Organization of the Thesis . .

II. TOTAL COMPUTER MODEL CONCEPTUALIZATION

Preliminary Input/Output Analysis

LREPS Computer System Flowcharts

Selection of Predominant Computer
Programming Language . . . .

III. THE DEMAND AND ENVIRONMENT SUBSYSTEM

Inputs, Outputs and Data Base
Requirements . . . . . .

Operating System . . . . . .

Supporting Data System . . . .

Page
. ii
. iii
. vii
.viii
. xii
. l
O 1
O 3
. 9
. ll
. 15
. 18
. 21
. 21
. 24
. 30
. 66
O 66
. 69
. 79

Chapter

IV. THE OPERATIONS SUBSYSTEM .

Inputs, Outputs and Data Base

Requirements .
Operating System .

Supporting Data System .
V. THE MEASUREMENT SUBSYSTEM

Inputs, Outputs and Data Base

Requirements .
Operating System .

Supporting Data System .

VI. MONITOR & CONTROL SUBSYSTEM .

Inputs, Outputs and Data Base

Requirements .
Operating System .

Supporting Data System .
VII. THE REPORT GENERATOR SYSTEM

Report Generator Inputs

DC-Based Reports .
LREPS Variable List

VIII. TOTAL COMPUTER MODEL

Operating System Linkages .

Activating Alternative LREPS

IX. RESULTS AND IMPLICATIONS

Versions

Results Concerning Research Questions
Implications for Future Research .

SELECTED BIBLIOGRAPHY . .

vi

Page

97

97
100
123
127
127
130
150
155
155
161
219
224
224
225
232
236

236
238

248

248
262

275

LI ST OF TABLES

Table Page

1. One-Year Validation Results . . . . . . . . 246

vii

Figure

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

ll.
12.
13.
14.
15.
16.
17.
18.
19.

LIST OF FIGURES

Stages of the Physical Distribution Network

LREPS Systems Model Concept .
LREPS Systems Design Procedure

Problem Input/Output Analysis .

Summary of Experimental Factor Categories

LREPS Total Computer System Flowchart

Exogenous Input Preparation .

Operating System's Interface with Input/Output

Report Generator System . . .

Criteria for Selecting Predominant Computer

Programming Language . . .

Daily Sales Quota Generation Variables

Calculation of Daily Sales Quota
Normal Sales Processing Variables
DC Daily Sales Processing Routine
Selection of Sample Invoices .
Sampled Invoice Analysis . .
Product Item Analysis--No. l .
Product Item Analysis--No. 2 .

Distance Check Routine . . .

viii

Page

10
13
22
25
29
31
31

31
70
70
71
71
80
83
83
85
85

Figure Page

20. Correlation Analysis . . .‘ . . . . . . . 88
21. DU Data Generator . . . . . . . . .9 . . 88
22. DU Selection, Agglomeration and Projection . . 90
23. Order File Generator . . . . . . . . . . 92
24. Individual Order Processing Variables . . . . 101
25. Customer Order Processing . . . . . . . .-101
26. Order Summary Processing Variables . . .- . . 107
27. Order Block Summary Processing . . . . . . 107
28. DC End-of—Day Processing Variables . . . . . 111
29. DC End-of—Day Activities . . . . . . . . 111
30. MCC Order Arrival Processing Variables . . . . 120
31. MCC Order Arrival Processing . . . . . .. . 120
32. DC Shipment Arrival Processing Variables . . . 122
33. DC Shipment Arrival Processing . . . .- . . 122
34. DC-MCC Link Information Generation . . . . . 124
35. Calculation of Service Measures' Variables . . 131
36. Calculate Service Measures . . . . . . . . 131
37. Inventory Characteristics Extrapolation

Variables . . . . . . . . . . . . . 135
38. Inventory Extrapolation Routine . . . . . . 135

39. Outbound Transportation Cost Calculation
Variables . . . . . . . . . . . . . 138

40. Outbound TranSportation Cost Routine . . . . 138

41. Inbound Transportation Cost Calculation
Variables . . . . . . . . . . . . . 141

42. Inbound Transportation Cost Routine . . . . . 141
43. Throughput Cost Calculation Variables . . . . 143

ix

Figure Page‘

44. Throughput Cost Calculation Routine . . . . . 143
45. Communications Cost Calculation Variables . . . 145
46. Communications Cost Calculation Routine . . . 145
47. Facility Cost Calculation Variables . . . . . 147
48. Facility Cost Calculation Routine . . . . . 147
49. Inventory Cost Calculation Variables . . . . 149
50. Inventory Cost Calculation Routine . . . . . 149
51. Distance Matrix Routine . . . . . . . . . 151
52. DC-DU OBT, Freight Rate Regression Analysis . . 153
53. Daily Event Processing Variables . . . . . . 165
54. Daily Event Activity Routine . . . . . . . 165
55. Quarterly Event Activity . . . . . . ., . 168
56. Beginning of Cycle Event Activity . . . .- . 171
57. EOQ Input/Output Analysis . . . . . .* . . 173
58. End-of—Quarter Activity Routine . . . . . . 173
59. LREPS Exogenous Input Routine . . . . . . . 177
60. Beginning-of—Quarter Activity Variables . . . 179
61. Beginning-of—Quarter Activity Routine . . . . 179
62. Fixed-Time Scheduler Routine . . . . . . . 182
63. Sales Modification Factor Calculation Variables . 184
64. Sales Modification Factor Calculation Routine . 184
65. Regional Weight Ratio Calculation Variables . . 187
66. Regional Weight Ratio Calculation Routine . . . 187
67. Inventory Management Variables . . . . . . 189
68. Inventory Management Routine . . . . . . . 190

X

Figure Page

69. Facility Location Algorithm Variables .- . . . 195
70. Facility Location Algorithm . . . . . . . 196
71. DC Facility Expansion Scheduling Variables . . 205
72. DC Expansion Scheduling Routine . . . . . . 205
73. Put DC Into Solution Variables . . . . . . 208
74. Put DC Into Solution Activities 3. . . . . . 208
75. Delete DC From Solution Variables . . . . . 212
76. Delete DC From Solution . . . . . . . . . 212
77. Expand In-Solution DC Capacity Variables . . . 215
78. Expand DC Size Routine . . .- . . . .- . . 215
79. DC to DU Link Information . . . . . . . . 217
80. DC to DU Link Information Generation . . . . 217
81. RPG DC-Based Reports' Activities . . . . . . 231
82. RPG Variable List Routine . . . . . . . . 234
83. LREPS Operating System Linkages . . . . . . 237
84. LREPS Operating System Input/Output Flowchart . 240

xi

LIST OF APPENDICES

Appendix Page
1. Data Base Information . . . . . . . . . 277
2. RPG DC-Based Sample Report Formats . . . . . 280

xii

CHAPTER I

INTRODUCTION

Sc0pe of the Research

 

To provide consumers with a wide assortment of goods
at the right time, in the right place and at the highest
profit potential, managers have increasingly viewed their
product distribution systems on an integrative basis.
Costs of transportation, warehousing, holding and handling
inventories and communications should be considered from
a total, integrated vieWpoint. Requirements of customers
for fast and consistent service, plus a rapid pace of
technological improvements throughout the entire distri-
bution system add to the plight of management in designing
efficient and effective distribution systems.

Management has the responsibility of not only
designing better distribution systems for supplying goods
to their customers but also administering these systems
within their associated channel structures. Bowersox,
Smykay and LaLonde define physical distribution manage-

ment as follows:

Physical distribution management is defined

as that responsibility to design and administer

systems to control raw material and finished

goods flow.1
This definition stresses finished goods distribution and
the physical supply of the raw materials for finished
goods' manufacturing.

Physical distribution matters also extend beyond
the limits and controls of the individual firm. To
properly plan a physical distribution system, total
costs and overall service levels experienced by all mem-
bers of the channe1(s) of distribution should be con-
sidered. To do otherwise could lead to suboptimization
in the attainment of channel as well as firm objectives
and goals.

One of the main problems, therefore, that confronts
firms is the balancing of the costs of physical distribu-
tion against the desired level of customer service. In
order to achieve market goals, the level of realized,
actual customer service must accomplish the target level
while keeping within the total cost constraint.

Given these types of questions, considerations and
problems, a specific need exists for the development of
improved planning models to aid firms in the design of
total physical distribution systems. Such a planning

model should be capable of assisting managers in ana-

lyzing, over time, the effect of alternative system

configurations within the dynamics of a changing market-
place and the internal business environment. The planning
model should be capable of assisting the managers in the
determination of the best time to implement physical dis-
tribution system modifications. Test evaluations of pro-
posed system changes should also be capable of analysis
with respect to sensitivity to different assumptions con-
cerning sales, costs, technological improvements and new
product introductions.

The overall objective of research conducted at
Michigan State University was to provide such a physi-
cal distribution planning model. The model has been
titled Long-Range Environmental Planning Simulator
(LREPS). This dissertation deals with the computeriza-
tion of the model on the Control Data Corporation 6500
computer using primarily the GASP IIA simulation lan—

guage and FORTRAN IV.

Situational Analysis

 

The dimensions of the physical distribution system
developed in LREPS extend the channel of distribution
from the production line to the point of ownership trans-
fer. Included are five basic elements of the physical
distribution operating system. The five elements are

classified as follows:

l)

2)

3)

4)

5)

the addition, deletion and modification of
distribution center facilities for the
holding and handling of finished goods
inventories;

the transportation of finished goods from
manufacturing centers or supply points to
distribution centers and then on to the
point Of ownership transfer;

the communication and processing Of customer
orders;

the physical picking and preparation of
orders for shipment dispatch to customers;
the holding and controlling Of the level of
finished goods inventories to supply customer

needs consistent with various inventory policies.

In terms Of the channel structure these five basic

elements Of the Operating system are considered at three

stages Of activities. A graphical View of this system

is shown in Figure 1. The three stages Of activities are:

l)

2)

the Manufacturing Control Center (MCC) at
which production is accomplished and inven-
toried at a Replenishment Center (RC);

the Distribution Center (DC) in which pro-

ducts are located adjacent to the market—

place;

 

STAGE 1:
MANUFACTURING
CONTROL
CENTERS
AND
REFLENISH-
MENT
CENTERS

 

 

 

 

STAGE 2:
DISTRI- RDC RDC

BUTION PDC FULL PDC PARTIAL
CENTERS LINE LINE

 

 

 

 

 

 

 

 

 

 

 

STAGE 3:

l
I
I
DEMAND
UNITS

 

 

 

PD REGION

 

 

PD REGION I

 

 

 

 

————— INFORMATION FLOW PRODUCT FLOW

REGION..THE REGION IS DEFINED BY THE ASSIGNMENT OF RDCS AND
DUS TO A PDC.

MCC.....EACH MANUFACTURING CENTER PRODUCES A PARTIAL LINE.

RC......REPLENISHMENT CENTERS STOCK ONLY PRODUCTS MANUFAC-
TURED AT COINCIDENT MCC.

RDC.....REMOTE DISTRIBUTION CENTER. FULL OR PARTIAL LINE. .

PDC.....PRIMARY DISTRIBUTION CENTER. EACH PDC IS FULL LINE

AND SUPPLIES ALL PRODUCTS TO DUS ASSIGNED TO THE
PDC REGION: PRODUCT CATEGORIES NOT STOCKED AT THE
PARTIAL LINE RDCS IN THE REGION ARE ALSO SHIPPED
BY THE PDC.
DU......THE DEMAND UNIT CONSISTS 0F ZIP SECTIONAL CENTER(S).
CSP.....CONSOLIDATED SHIPPING POINT.

 

 

Figure l.--Stages of the Physical Distribution Network1
1D. J. Bowersox, et al., D namic Simulation of Physical

Distributigp Systems, Monograph East Lansing, Michigan:
DiviSion Of Research, Michigan State University, Forthcoming).

 

3) the individual customer's demand or
agglomerations of customer demands
identified as the Demand Unit's (DU)
stage.

The distribution center stage, Stage 2, incorporates
four basic types Of distribution nodes. Primary Distribu-
tion Centers (PDC's) handle a full line of products and
have the potential of serving all demand units in a defined
region of the firm's total market area. A distribution
center that handles a full line Of products and is not the
primary distribution center in a market region is called
a Remote Distribution Center—Full line (RDC-F). A RDC-F
serves only part Of the DU's in a region but it serves
them entirely. A RDC that only supplies part of the
product lines to its assigned DU's is called a RDC-
Partial line (RDC-P). The PDC tO which the RDC-P is
linked will supply the other products to the assigned RDC-P's
DU's. Also included in the DC stage are Consolidated
Shipping Points (CSP's). CSP's are very similar to
RDC-P's but handle no products. They serve as geograph-
ical aggregative points for the demand Of several DU's.
The total demand for several DU's is agglomerated and
then shipped on a break-bulk basis to the geographical
point Of demand.

Given this general framework Of analysis which fits
most firms in the manufacture of both industrial and

consumer package goods, the LREPS project team

 

conceptualized a simulation model. A research monograph
written by the LREPS project team provides a detailed
discussion Of the purpose Of the model, general class

of problem tO be modeled, the conceptual model, the
capabilities of the model plus the use Of simulation as
the appropriate solution technique.2 Simulation was
considered most appropriate when considering the system
characteristics and complexities plus the research
Objectives. The range of simulation is described in
Figure 2 which illustrates the model's major subsystems.
Each Of these subsystems was conceptualized to emphasize
some particular aspect Of the Operations of the physical
distribution system.

The Demand and Environment (D&E) Subsystem focuses
on the major inputs Of customer mix, product mix, and
order characteristics, plus forecasting and allocating
sales among demand units. The Operations (OPS) Subsys-
tem processes simulated customer orders through the
major physical distribution activities or elements
associated with transportation, facilities, communications,
materials handling, unitization and inventory control.
The Measurement (MEAS) Subsystem develops the criteria
for evaluating alternative distribution system configura-
tions. The Monitor & Control (M&C) Subsystem is the model
supervisor and controller section of LREPS. The LREPS
controller not only effects model feedback responses from

past activities but also incorporates changes in

.muwmum>wca mumum somMEOflz .soummmmm mo :OHmmbma

 

 

umoocoo H0602 mEoummm mmmmqul.m ousmflm

thm>m no >m<mz=om

 

.mEoumMm doausnfiuumwa Hmofimwnm mo coflumasfiwm OHEOGNQ ..Hm um .xomnm3om .b .0

 

 

 

 

>HH4HmHXm4m

mo mmm2m<mz

wuH>mmm
mm4<m
Hmou

 

 

[—

m0h<mmzmw

thm>m

haemmm

wu~>mmm

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

mmoeo<a
Leno:
mmn<m
¥o<mamm1 mmoz<xo ¥o<mommu
L 36 E
nomezoo
>21
0 w z
mmmamo
amz<ee to
ana p12: oohn<
>21
mmn<m zzoo mw4<m
Fmoo o<1 n<=eo<
w<mz mao m w o

 

 

 

A.mcfleoosuuom

"comwnoaz .mcflmcwq ummmv nmwumocoz

H

 

mmqam zomm~omm
machu<m Hmou
mmaoz dmz<mh
XHZ Husoomd
XHZ mmZOHmDQ

hm<ummou wm4<m
mmmhmz<m<m be:

 

 

 

thm>m ozmh<mmao

._

_

_

_
IIL

kaw>m
<h<a
ozmkmOQQDm

_
_
_
_
_
mmemo_
_
q
_
_

 

 

,n

ul’

 

 

 

environmental factors and conditions. These controller
actions, therefore, dynamically affect decisions con-
cerning future facility configurations, transportation,
communications, inventory policies plus DU, DC, regional
and MCC sales. Each Of the major subsystems is supported
by a data analysis, preparation and reduction system
labeled the Supporting Data System. The output is con-
verted into managerial reports by the Report Generator

(RPG) System.

System Identification

 

Figure 3 identifies the system design procedure or
logical progression Of activities utilized in the devel-
opment of the LREPS simulation model. The shaded area
of Figure 3 illustrates the focal point Of this disserta-
tion. In the "Problem Definition and Feasibility Study"
the goals Of the research were examined and substantiated
via a preliminary collection and analysis of data. The
outputs Of this activity were a detailed problem state-
ment, the specifications for a mathematical model and the
boundary conditions on a defined set of feasible alterna-
tive solutions.3 Given the outputs of the feasibility
study, the next step was to develOp an abstract representa-
tion of the mathematical model. This step emphasized the
specific definition Of: (1) the system boundaries and
assumptions, (2) the inputs and outputs, (3) the constraints
on the inputs, outputs and system configuration, (4) the

criteria for evaluating alternative systems, (5) the design

 

10

 

 

 

 

 

 

 

 

 

PROCESS
EXP DESIGN 3. am
MODEL USAGE
I/O
BIDCK

 

Figaro 3.-LREPS Systems Design Proceduro1

1D. J. Bowersox, et al., Dynamic Simulation of Physical
Distribution Systems, Monograph (East Lansing, Michigan:
Division of Research, Michigan State University, Forthcoming).

 

11

parameters that will be the basis for experimenting with
the model, (6) the estimation Of parameters via further
data collection and analysis, and (7) a preliminary
evaluation Of model validity. The output Of this mathe-
matical modeling process served as the basis for con-
structing the computerized model.4

In formulating the computerized model, an overall
approach was required. This approach is discussed in
the "Methodology" section of this chapter. Various pro-
gramming and systems techniques also had to be reviewed
for their applicability in the computerization process.
These techniques are discussed as the need arises.

The result or output Of the activities associated
with this dissertation is an "Operational Computer Model."
This computer model serves as the input into the applica-
tion areas that include detailed model validation plus
sensitivity analysis and experimentation.

The output Of the last two processes in the overall
system design procedure is a set of critical management
parameters that aid in solving the defined research pro-
blems.

Detailed Problem Statement and
Researchable Questions

 

 

Analysis Of the mathematical model served as the
basic input for developing an Operational computer model.
The boundary conditions for the system and feasible solu-
tions were defined in terms Of economic, financial, social,

political and physical characteristics Of the system. The

11

parameters that will be the basis for experimenting with
the model, (6) the estimation Of parameters via further
data collection and analysis, and (7) a preliminary
evaluation Of model validity. The output Of this mathe-
matical modeling process served as the basis for con-
structing the computerized model.4

In formulating the computerized model, an overall
approach was required. This approach is discussed in
the "Methodology" section of this chapter. Various pro-
gramming and systems techniques also had to be reviewed
for their applicability in the computerization process.
These techniques are discussed as the need arises.

The result or output of the activities associated
with this dissertation is an "Operational Computer Model."
This computer model serves as the input into the applica-
tion areas that include detailed model validation plus
sensitivity analysis and experimentation.

The output Of the last two processes in the overall
system design procedure is a set of critical management
parameters that aid in solving the defined research pro-
blems.

Detailed Problem Statement and
Researchable Questions

 

 

Analysis Of the mathematical model served as the
basic input for develOping an Operational computer model.
The boundary conditions for the system and feasible solu-
tions were defined in terms of economic, financial, social,

political and physical characteristics Of the system. The

12

model's inputs were classified as either controllable or
uncontrollable. The outputs Of the system model included
the alternative criteria for evaluating a tested physical
distribution plan. The system outputs included such items
as sales, costs, service and flexibility measures. Given
the system characteristics, Figure 4 illustrates the
various aspects considered in computerizing the mathema-
tical model. The detailed problem was to develop a com-
puterized model that satisfied the needs and specifications
of the abstract mathematical model, the validity of the
model, the model's data base requirements and stayed
within the constraints Of the defined computerization
process.

The constraints on the inputs, outputs, Optimizing
parameters and the overall process Of formulating the
computer model were phrased in the form Of researchable
questions. These researchable questions, which lent
direction to the computerization process, are:

1) What programming languages will facilitate

the development Of a reliable computer
model including the supporting data
system and the report generator system?

2) What model building procedures will

facilitate the development of the com-
puter model, the later SOphistication
Of the model's defined activities, the

broadening Of the model to encompass

13

 

 

 

 

 

OUTPUTS
1. Documented,
INPUTS operational
model
1. Abstract
represen- COMPUTER 2. Model com-
tation of patibility
system model IMPLEMENTATION among g
2. Model -—-fi OF :zigzizgt
validity operating
:pecifica- MATH MODEL systems
one
3.. validity

 

3. Model data
base require-
ments

OPTIMIZING PARAMETERS 5.

1.

3.

of model

4. Cost and time
of model com-
puterization

Efficiency of
computerized
Personnel - number of model
systems . programming,
and keypunching per-

sonnel

Computer Operating
systems available -
including the avail-
able programming
languages

Quality of documen-
tation of computer
model

Figure lbw-Problem Input/Output Analysis

3)

4)

5)

6)

7)

14

additional horizontal and vertical aspects
Of the total business system and satisfy

the strong desire for universal applica-
bility among packaged-goods firms?

What computer software and hardware features
will allow the structuring Of the simulation
model's data base and its input/output
requirements that will minimize reprogramming
these structures for alternative LREPS
versions?

What computer software and hardware features
will promote the efficient processing Of the
great amounts of information that will
accompany a model spanning a maximum ten-
year planning horizon?

What is the most efficient way to write the
model's output in order to provide printed
reports of the essential data and to provide
storage that can be easily accessed later as
input tO programs for further simulation
results analysis?

Can a LREPS model be developed that will be
highly compatible among different computer
Operating systems (hardware and software
combined)?

Can a model be developed that will run on

medium-size computer operating systems?

8)

15

Can a computer program Of the main operating

system of LREPS be developed that will:

a) Cycle through a ten-year planning horizon
within a total elapsed computer time Of
30 minutes?

b) Fit within a computer memory limitation
Of 36K decimal words?

c) Require nO more than three input/output

files?

Methodology

 

In order to develop a computerized operational model

Of LREPS and attempt to satisfy the above researchable

questions, the following approach was developed:

1)

2)

Specify the computer system model's data
base in detail using the mathematical
model specifications and the broad system
flowcharts.
Evaluate and select the predominant com-
puter programming language for the simu-
lator. The selection was from general
compiler languages such as FORTRAN or
ALGOL and from simulation languages such
as GASP, FORDYN or SIMSCRIPT.
a) A set Of criteria for selecting this
predominant language was developed

in order to make this decision.

3)

4)

16

Segregate and program the computer model

activities and their respective data base

requirements according to these three

main sections:

a)

b)

C)

Supporting data systems which were
primarily developed for collection,
preparation and reduction Of data
inputs to the LREPS Operating system;
Operating system programs which were
those programs and activities directly
involved in the LREPS simulator;
Report generator programs for the
develOpment Of the reports containing

the model's results.

For each individual subprogram associated

with the LREPS procedure:

a)

b)

C)

d)

Identify the respective system model
activities within the program;
Identify the information flowing in
and out Of the subprogram plus any

key endogenous variables;

Block diagram the basic, logical steps
for generating the program's outputs
after considering alternative computer
systems and programming techniques;
Code the program using the most appro-

priate computer programming language(s);

17

e) Test and debug the program using a test
case that had been develOped;

f) Present any computerization problems,
and any peculiar or unique programming
techniques.

5) Combine the subprograms and their respective
inputs, outputs and data base requirements,
making any necessary revisions as a result
Of this step.

6) Test and debug the combined subsystem models
to Operationalize and calibrate to the actual
system.

a) the D&E subsystem was first programmed
and calibrated;

b) The D&E and OPS subsystems were then
merged tO develop the second LREPS
model and it was also calibrated.

c) The D&E, OPS and MEAS subsystems were
merged into the third version Of LREPS
which also had tO be calibrated.

d) Finally all four major subsystems were
merged into the first total LREPS model.
This model was calibrated and served as
the basis for the first series Of experi-
ments, utilizing LREPS.

The above approach required feedback at each level

of development as more detailed and concrete system

characteristics were formulated.

18

Organization Of the Thesis

 

This dissertation is organized into nine chapters.
Following this initial chapter, Chapter II presents the
organization Of the total computer model for LREPS.
Chapter II also defines many Of the important computer
modeling concepts that are used throughout the disserta~
tion. In the last sections of the second chapter, the
evaluation Of alternative computer programming languages
plus the selection Of the predominant computer program-
ming language are discussed.

Chapters III through VI discuss each of the four
major subsystems into which LREPS is segmented. Each of
these chapters is subdivided into three sections. Sec-
tion one is titled "Inputs, Outputs and Data Base Require-
ments." This subsection broadly discusses the subsystem's
inputs and outputs and it presents an overview Of the
computer subprograms or activities that are discussed in
detail in the latter sections Of the chapter. The second
section Of each chapter, titled the "Operating System,"
presents the computer activities directly involved in the
Operation Of the LREPS simulator. The "Supporting Data
System" is the title Of the last subsection. This subsec-
tion represents and discusses the computer activities that
are required in the analysis, preparation and reduction
Of the data inputs.

Chapter VII describes that part Of the total computer

system in which the output reports are prepared. This

19

chapter is titled "The Report Generator System" and is
divided into three sections. The first section discusses
the inputs to the report generator (RPG) while the last
two sections describe the reports prepared in order to
examine the results Of a simulation cycle.

Chapter VIII presents a discussion Of the Operation-
alized total LREPS computer model. This discussion
includes: 1) a description Of the computer linkages
between the Operating system's subprograms and major
subsystems; 2) the implementation procedures followed in
developing the Operational computer model; and 3) the
results from a preliminary validation Of model outputs.

Chapter IX presents the results Of this thesis in
relation tO the researchable questions stated in Chapter I.
Implications for future research are also discussed in

relation tO research results.

CHAPTER I--FOOTNOTES

1D. J. Bowersox, E. W. Smykay, and B. J. LaLonde,

Physical Distribution Management (New York: The MacMillan
CO., 1968), p. 5.

2D. J. Bowersox, et al., Dynamic Simulation Of Physi-
cal Distribution Systems, Monograph (East LanEing, Michigan:
Division of Research, Michigan State University, Forthcoming).

3Ibid.

40. K. Helferich, Development of a Dynamic Simulation
Model for Planning Physical Distribution Systems: Formula-
tion Of the Mathematical Model (unpublished Doctoral Disser—
tation, Michigan State University, 1970).

 

20

CHAPTER II

TOTAL COMPUTER MODEL CONCEPTUALIZATION

Preliminary Input/Output Analysis

At a broad level the inputs and outputs Of the LREPS
model were originally classified in the categories exhib-
ited in Figure 5. This figure was developed in the con-
ceptualization Of the system boundaries and the experiments
using the LREPS simulation model. The system model out-
puts included the criteria Or target variables for
evaluating alternative distribution plans. These outputs
included measures Of sales, service and total cost plus a
measure of flexibility among different distribution plans.
Flexibility was concerned with the amount Of risk involved
in a given plan when considering the uncertainties Of the
future.

The development Of the specific outputs Of the
system model is evolutionary in nature. The initial
reports from the model Report Generator were reports
that summarized the results of the model for individual
Simulation cycles. A simulation cycle was considered

one pass through a planning horizon.

21

22

W
SALES

CUSTOMER SERVICE
PHYSICAL DISTRIBUTION SYSTEM COSTS
PHYSICAL DISTRIBUTION SYSTEM FLEXIBILITY

N O B E IA ES
ORDER CHARACTERISTICS

PRODUCT MIX

NEW PRODUCTS
CUSTOMER MIX
FACILITY NETWORK
INVENTORY POLICY
TRANSPORTATION
COMMUNICATIONS
UNITIZATION

UNCONTROLLABLE VARIABLES
MARKETING ENVIRONMENT

TECHNOLOGY
ACTS OF NATURE

Figure 5.--Summary of Experimental Factor Categoriesl

1D. J. Bowersox, et al., Dynamic Simulation Of

Physical Distribution Systems, Monograph (East Lansing,
Michigan: Division Of Research, Michigan State University,
forthcoming).

 

23

On a more detailed basis, the system outputs included
part Of the endogenous variables generated in the system
as a result of the controllable and uncontrollable exo-
genous variables that were inputted into the model. Naylor,
Balintfy, Burdick and Chu define the system inputs and
outputs in this way:

Endogenous variables can be best defined as

the dependent or output variables of the sys-
tem and are generated from the interaction Of
the system's exogenous and status variables
according to the system's Operating character-
istics. Exogenous variables are the indepen-
dent Or input variables of the model and are
assumed to have been predetermined and given
independently Of the system being modeled.
Exogenous variables can be classified as
either controllable or uncontrollable. Con-
trollable or instrumental variables are those
variables or parameters that can be manipulated
or controlled by the decision makers or policy
makers Of the system.1

The system model inputs included controllable factors
related to the firm's product mix, customer mix, the
characteristics of the orders, the management policies
related tO the channel(s) Of distribution plus the list
Of factors related tO alternative physical distribution
systems.

The uncontrollable factors included the assumptions
concerning cost-Of-living increases by area Of the coun-
try, real rate increases in cost categories, growth rates
concerning environmental, demographic factors such as
pOpulation, and the delay times for alternative modes of

transportation or communications given that the mode was

selected.

24

Given these broad categories of inputs and outputs
of the system model, the mathematical model was developed
to describe the activities necessary to process and pro-

duce this information.

LREPS Computer System Flowcharts

Total Computer System Flowchart

 

After the system was mathematically modeled, the
computer formulation of the model required a general
overview Of how to interrelate all the described activ-
ities into an efficient computer model. The philosophy
was to develop a total computer system that would effi-
ciently and effectively produce the desired system
outputs. The essential goal in programming the model
was to process the model's data with the least
redundant operations possible. This goal was especi-
ally critical when considering the large amounts Of
information that would be manipulated in the model where
the danger was to waste much computer time and effort.
In line with these desires, Figure 6 was developed tO
conceptually direct the overall computerization Of
LREPS .

As viewed in Figure 6, much Of the data needed
within the Operating system Of LREPS was prepared Off-
line in the supporting data system. This Off—line data
was read into the Operating system as exogenous inputs

at specified periods of time. Also supplementary or

25

LREPS
COMPUTER

MODEL
SUPPORTING

0 DATA
DATA COLLECTION a PREPARATION SYSTEM

‘— _—

 

 

 

 

 

 

ORDER MODEL INPUT
FILE INPUTS IINTERFACE

 

__ V ___ ._ _ -_____l__

 

 

D 8 E FEEDBACK I

M V l

-.I—r _L __

 

 

 

 

OPERATING
SYSTEM

 

 

 

 

 

 

 

 

 

 

 

 

 

  

 

 

SUPPLE' IOUTPUT
INTERFACE
' ‘ _—
OUTPUT ANALYSIS REPORT
L—U— GENERATOR

 

ISYSTEM

 

 

Figure 6.--LREPS Total Computer System Flowchartl

1D. J. Bowersox, et al., Dynamic Simulation of
Physical Distribution Systems, Monograph (East LansIng,
Michigan: DivisIOn of Research, Michigan State Univer-
sity, forthcoming).

 

26

or identifying information not needed in the Operating

system was sent directly to the report generator system.

LREPS Data Base

 

In developing this data manipulation concept, a
total system data base had to be defined. The total data
base included all the information that was needed in the
system in order tO develOp and analyze the results Of
simulation cycles. This data base was further segregated
into two classes. The first class Of data was the common
data base needed within the Operating system Of LREPS
that was to be shared among, between, or used individ-
ually by the major subsystems Of the model. The major
subsystems are, as already defined, the D&E, OPS, MEAS
and.M&C. This first class of information is listed in
Zhgpendix l. The other class of information was the

SLupplementary information needed by the report generator
tC> prepare the managerial reports.

The first class of information along with the system
acrtivities described by the mathematical model serves as
tiles basis for discussing each Of the major subsystems Of
tilea model. Each subsystem, such as the D&E, includes a
di scussion Of:

1) The Operating system activities that

manipulated the endogenous variables.
These generated endogenous variables

served as the output Of the subsystem

27

that went either to another subsystem
or to the report generator system.

2) The supporting data system activities

that generated the exogenous inputs
required in the operating system.

By examining the operating system's common data
base in Appendix 1, it is noted that the data was classi-
fied as to type of data, how often it was changed, whether
it was an endogenous or exogenous change, what subsystem
altered or set it, what subsystem used the data and the
mode of the data. The mode was used to classify the
data as integer, real or packed information. In addi-
tion, many of the variables were classified as exogenous
for only the first versions Of LREPS. Later the addi-

‘tion Of a LREPS modular activity could produce some Of

tinese variables endogenously.

Ctnnputer System Interfaces

After the Operating system's common data base was
(fiaxzeloped, a problem was how to control the inflow Of
EExogenous inputs at Specified time intervals without
1'1<‘3.\7:ing each major subsystem inputting its own informa-
‘tixsrn Therefore, the concept Of an interface between
Flier Operating system and each of the other computer
Systems was developed. An interface was defined as the
nOCL31 point in data flow where two major computer sys-
‘tQHNS interacted. The input interface was segmented

lntKD two parts. The first part was the order file.

28

Because Of the potentially large amounts of information in

this file given the decision had been made to work with
individual customer orders, the orders were generated

off-line in the D&E supporting data system and read in as
a separate file. The other segment of the Operating sys-
tem's inputs was the file containing the remaining exo-
genous inputs. It should also be noted that these exo-

genous inputs into the Operating system might have been

endogenously created in a supporting data system activity.

The decision was made not to incorporate certain activi-
ties directly in the operating system when efficiencies
in computer processing could be achieved.

The last file Of exogenous inputs was designed to
agglomerate all Of the model's subsystem inputs into one
:file that would be inputted into the M&C subsystem. The
M&C was not only conceptualized as being the supervisor
Elna controller Of the model but also the gatekeeper con-
trolling the flow Of exogenous inputs into the operating

SYstem's common data base.

EQEEQPS Detailed Computer System Flowcharts

 

Figure 7 illustrates in more detail the supporting
Chatza system program to collect and prepare the exogenous
inPuts for each specified time period. This program is
directly related to a catalogued or segmented data base
EinSi provides a convenient method for preparing and con-

trolling the inputs into the Operating system. Figure 8

 

DATA
PREP

 

 

EXOGENOUS
INPUTS

 

 

PROCESS
INPUT
CATALOGS

 

 

 

 

 

 

 

 

29

Program to collect and
prepare exogenous inputs

Read exogenous inputs by
specified time period

Process all catalogs of
inputs for time period

Input interface

Check to see if all specified
time periods processed

End of run

Figure 7.--Exogenous Input Preparation

30

illustrates the operating system's interaction not only
with the input interface but also the output interface.

As Figures 6 and 8 illustrate, the M&C subsystem
was conceptualized as the gatekeeper controlling the
outflow Of information from the Operating system. M&C
basically wrote an output interface containing run con-
trol information, specific distribution center informa-
tion and the common data base for processing by the
report generator system.

Figure 9 illustrates the activities Of the report-
generator system in processing not only the Operating
system's output but also the supplementary information
sent to it by the supporting data system. Both cyclic
and.multi-cyclic reports are conceptualized as being pre-
Pared in this computer system.

Selection of Predominant Computer
Programming Language

 

 

Egaggguage Selection Criteria

The purpose Of this section is to discuss the sel-
ecztzion Of GASP IIA as the computer programming language
Exrfiadominantly used in programming LREPS. The alternative
languages evaluated are general-purpose languages such as
F01STRAN or ALGOL and simulation languages such as GPSS
(Dr' SIMSCRIPT. Predominance must be stressed because
(btlher programming languages besides the main language

Were used to process much more efficiently some of the

31

Sean uoueneceo fonSTKO 9:63

55 no 16

condone 3.8%.—
.8536 .3- = one 3 :85

tome.—
Heaheweaes ooh-op chemot—

Aseuehe ease 9.3.8.3:-
5? eoeuuevcw annugv
face: vouaeov no.“ cued
Faceieannse 5 owns:

eHC #533 59G
sodas-Lou: cocoa: uoeufifi

:oauoee cos-nosem uneaem

35 Ace .8235 2.3.6

3.8%.— Her—omens:
anemone ea meanness—

2
EOE » 5.50me
Mac:

 

20am:
EHEQ
Bin—mam

 

 

 

_

 

82H
,E<bzmaqmm:m
moan:-

 

 

 

 

 

 

asnuso\¢§ 5c. eoeuuovsn Plenum 93.592556 enema

5: co as

woof—em 2:3
caved—Ida fine anoooum

:oaueuono Eocene.“
unefi 8C nod—mo.— unease

BESS 823 2.3 do as

.823 2.3 you
3.5.: nsccemoxo 2300.5

8:21 mafia
«.0332: none 3000.5

:0qu m5 «chemo mg

2
coat man—oak
was x 58:

magnum
ESQ

 

 

 

 

 

 

 

 

32

activities in the total-system model. The use of these
other languages took place in the supporting data,
operating and report generator systems.

The literature is abundant with articles comparing
and evaluating alternative programming languages. Naylor,
Balintfy, Burdick and Chu state:

Clearly one way to approach programming

simulation experiments is to write a special
program for simulating each system to be
studied in one of the well-known, general-
purpose languages such as FORTRAN, ALGOL,
COBOL, or IBM's PL/I. To be sure, this
alternative offers the programmer maximum
flexibility in (l) the design and formula-
tion of the mathematical model of the system
being studied, (2) the type and format of out-
put reports generated and (3) the kinds of

simulation experiments performed with the
model.2

However, these authors further comment on the diffi-
cnalty encountered in trying to write routines to step the
HKMiel through the time periods of the model. To aid the
Ctnnputer implementers of simulation models and to faci-
listate model experimentation, simulation programming
1«Elnguages have been developed. These simulation lan-
guages serve essentially three vital purposes:

1) Reduce the programming task.

2) Provide conceptual guidance.

3) Allow flexibility for change.

Essentially a simulation package consists of the language
used by model builders and the "run-time" routines which

are present during the simulation.

33

After reviewing many of the important pieces of
literature concerning the available programming languages
and their applicability to simulation, criteria for
selecting the most appropriate language for the formula-
tion of the computer model were required. The language
selected had to be appropriate given the nature of the
model plus be able to manipulate efficiently and effec-
tively the data base of information described in the
previous section of this chapter. The essential nature
of LREPS was a hybrid system that had both fixedpand
variable-time activities occurring during the simulated
planning horizon.

The set of criteria for evaluating and comparing
many of the available languages are listed in Figure 10.
ITuase ten criteria were used to screen many of the
Ennailable languages such as those listed in Tables II.l

arui 11.2 in the article by Teichroew and Lubin.3 After
'tfua screening process, four languages were examined in
detail as possible predominant programming languages.
F'inally, a predominant language was selected. The next
Sections of this chapter present a detailed discussion
(15’ the ten criteria, the four selected languages using
tJIGB ten criteria and the reasons why the predominant
language was selected.

The first criteria in Figure 10 refers to the struc-
tnerE of the programming language and how it lends assist-

anCe in getting the system model computerized.

10.

34

PROGRAMMING LANGUAGE STRUCTURE
LEVEL OF REQUIRED PROGRAMMING SKILL

EASE OF CONVERTING LOGICAL BLOCK DIAGRAMS TO
COMPUTER PROGRAM

SIMULATION PROCEDURES ASSOCIATED WITH

A. INITIAL VALUES

DATA GENERATION AND MANIPULATION
TIME FLOW MECHANISMS

OUTPUT ASSISTANCE

STACKING OF A SERIES OF CYCLES

I'TIUOEIJ

DEBUGGING AND ERROR ASSISTANCE OFFERED BY
LANGUAGE

COMPUTER COSTS OF COMPILATION AND EXECUTION

COMPATIBILITY OF LANGUAGE AMONG DIFFERENT
COMPUTER OPERATING SYSTEMS

AVAILABILITY OF COMPUTER HARDWARE
EASE OF CHANGING SYSTEM MODULES

APPLICATIONS OF LANGUAGE TO DATE

Figure lO.--Criteria for Selecting Predominant

Computer Programming Language

35

Specifically, the language must be compatible with the
type of system model. Teichroew and Lubin refer to this
when they discuss "what flows in the simulated world?"
and "what determines when a change occurs?"4 They con-
tinue their discussion of types of system models by
classifying them as either continuous-change or discrete-
change models.5 Krasnow and Merikallio discuss these
different systems-~continuous and discrete--and lan-
guages that can process both types of systems.6 Tocher
refers to this system structure when he discusses the
organization of the program required to piece together
the various blocks of the program into a consistent
order so that execution will change the system configu-
ration approximately at each instant of time.7

In regards to the structure of the language one
must also consider the conceptual guidance provided by
the language in not only computerizing but also in
developing the system model. This concept was stressed
by several authors where they emphasized the overlap in
mathematical modeling and formulation of the computer
model. Naylor, Balintfy, Burdick and Chu mention this
when they discuss the languages that they compare based
on language components.8 Krasnow also discusses this
when he notes:

The user can then utilize a way of approach-

ing his problem which both reduces the intel-

lectual task and assures compatibility with
computer requirements for implementation.

36

Associated with conceptual guidance several authors
have commented on the assistance provided in getting a
simulation model computerized via written subroutines to

10'11'12 Also associated

produce the model's activities.
with the subroutines that are already available for sys-
temizing the model, one must consider the language compo-
nents that are available for modifying the state of the
system. Krasnow mentions the characteristics of the
language for arithmetic operations, set operations and

13 This is also men-

logical testing and program control.
tioned by Naylor.l4 The last thing to be mentioned in
this area is the flexibility and ease of use of the
language. Krasnow and Merikallio mention the flexibility
and range of using simulation languages considering simu-
lator-defined concepts, user-defined concepts, concepts
and values defined at the start of the simulation and
during the simulation.15

The second criterion is concerned with the level of
programming skill required. This criterion is essenti-
ally concerned with the ease of learning the language.16’l7
The language may be a very powerful language but only if
one has used the language for several simulations. One
must, therefore, consider the availability of experienced

18'19'20 A language may

programming skill and its cost.
be available but because it is not easy to learn or
sophistication only comes with experience, one may not

be able to obtain people to assist you in computerizing

37

the model. This is especially true if one is under a
tight deadline for implementation. In addition, one of
the biggest problems with using many simulation lan-
guages is the lack of adequate documentation and instruc-
tional material.21 If good instructional material
exists plus the language is not difficult to learn,
the programming task can be greatly reduced.22
The third criterion is again one that cuts across
the mathematical modeling and computerization tasks.
It is concerned with the ease of converting logical
block diagrams to computer programs. Some of the lan-
guages offer special flowcharting symbols that help in
systemizing the model plus lead directly to model com-

23’24 If one does a number of simulations

puterization.
and there is good documentation, then the use of these
Special flowcharting symbols can be very helpful. One
problem that frequently arises is that the flowcharting
symbols are not consistent between languages. Thus,
this aspect promotes inflexibility in the use of differ-
ent languages.

The fourth criterion is concerned with some of the
Special features of the language in doing some of the
more or less menial tasks in programming. Given that
one has determined the type of system model and the
desired outputs, simulation languages offer assistance

25

in initializing values and arrays, data-generation

26,27

routines, data-manipulation operations,28 output

38

29,30,31,32

assistance, and stacking of a series of cycles

33’34 Krasnow has a

through a simulation computer model.
good discussion of these simulation procedures in his
article.35 Krasnow and Merikallio even talk of the man—
machine interaction during simulation execution that
some languages are beginning to offer.36
The next criterion deals with the debugging and
error assistance offered by the language. In getting
the model to execute, many of the languages have tracing
routines to help one know where he is in a simulation
either at the time of errors or change in simulated

time.37’38’39

They can be very helpful given that the
supporting instructional material clearly states just
how to use these features. All the languages provide
the normal diagnostics for errors associated with pro-
gramming rules.

The sixth criterion deals with the computer costs
of compilation and execution. The efficiency ofxa‘~
computer run is concerned not only with execution time
but also the time that it takes to get the program com-
piled into a machine language program that can be
executed on the computer. Also involved in the program-
ming of the model are the size and the type of data
structures that are available with the use of a program-
ming language. Data structure types include simple

40,41

variables, arrays and packed variables. If a

simulation model is input/output bound, the capability

39

of multi-programming execution can also be very important
in reducing computer costs.

The seventh criterion is concerned with the compat-
ibility of the language among different computer operat-
ing systems. A computer Operating system is defined as.
that combination of computer hardware and software that
approaches the Optimum use of a particular computer.
Given the operating systems that are available on differ-
ent sizes and makes of computers, one can be restricted
by not only the available computer systems but also the

compiler requirements on the system.42

In addition, the
reliability of the compiler must be considered. A com-
piler may be available but never effectively tested and
utilized.

The eighth criterion concerns the availability of
computer hardware itself. Often one is restricted by
the computers that are at his disposal. Some languages

43,44

are just not available on certain machines. This

criterion is also concerned with the availability and
use of auxiliary equipment such as disk or tape files.45
Massive amounts of information may require disk or tape
files. Another aspect that is important in determining
the availability of a certain computer system is the
direct cost of using the system. If one has available
a system that is partly financed by outside or other

sources either because of promotional reasons of computer

manufacturers or educational discounts, then this can be

40

a major factor in determining whether one uses a certain
system and programming language. Also involved in this
availability of hardware is the proximity of the computer
to the personnel who are programming, debugging and using the
model. If one has to go many miles to use a certain system
or cannot use terminals for testing and/or running the model
because the Operating system is not oriented toward a
particular simulation language, then one may also have
to be satisfied with a less powerful language.

The ninth criterion has to do with the ease of
changing the system model for changes in the system
being modeled or to test the results of the system for
system-design modifications.46 Although general-purpose
languages allow one to model a system in more detail,
they cut down on the flexibility and ease of system
changes. Simulation languages promote this type of
system flexibility.

One of the very important criterion for evaluating
languages is a record of the applications to date using
the language.47 If others have used a language for
similar undertakings, it may indicate that a language
is good for certain types of problems. Further, the
language may have been written to handle specific types

of problems with great ease.48

41

Alternative Languages Evaluation

 

The purpose of this section is to discuss alterna-
tive programming languages considered for operationalizing
LREPS. The following subsection discusses important fac-
tors in the selection of certain types of simulation
languages consistent with the nature of the defined system
model. The next subsections discuss four programming lan-
guages that were seriously considered for the computeriza-
tion process.

Preliminary Screening of Languages.—-The LREPS model

 

was designed to be general or universal in nature with a

high degree of flexibility in processing system entities

or objects. Primary emphasis in model design was the

easy adaptation of the model to a large class of multi-

product, consumer and industrial, packaged-goods firms.

In serving these classes of potential users, the purposes

of the system model were conceptualized as both lending

direction in the strategical design and testing tactical

or detailed procedures for day-to-day operations of

alternative physical distribution system configurations.
Given the desire for universal applicability and

for serving the general purposes specified above, the

ability to process alternative combinations of system

entities and dynamically change system state over simulated

time was necessary. A more detailed list of system entities

than that given in Figure l of Chapter I includes: (1)

demand units of potential agglomerated customer demand,

42

(2) customer classes of trade, (3) tracked product items,
(4) customer orders, (5) dispatched customer orders from
demand units to distribution centers, (6) full- or partial-
line distribution centers for processing customer orders,
(7) dispatched customer shipments from distribution centers
to demand units, (8) customer backorders resulting from
product stockouts at distribution centers, (9) multi-pro-
duct reorders from distribution centers to supplying
replenishment centers, (10) multi-reorder, dispatched
shipments from replenishment centers to distribution cen-
ters, (11) potential distribution center locations, (12)
manufacturing control centers for replenishing product
inventories of replenishment centers, (13) inventory
categories for grouping similar tracked products and (14)
market regions to allow for variations in regional customer
demand and service requirements.

Procedures for processing system entities, either
singularly or in combination, were conceptualized on a
discrete-change, event basis. Preliminary system activity
analysis indicated that detailed modeling procedures were
necessary to: (I) randomly allocate daily customer orders
to a subset of all demand units, (2) dispatch customer
shipments either on a daily basis or in consolidated ship-
ments on greater than a daily basis, (3) process reorders
dispatched from distribution centers to replenishment
centers, triggered by varying inventory control values

and occurring on an intermittent basis, and (4) dispatch

 

43

shipments from manufacturing control centers to distribu-
tion centers on an intermittent basis which varied with
the accumulated amount of product on reorder plus other
time-oriented, shipment dispatch policies. The use of
discrete-change, event-processing programming languages
was considered appropriate if complex system activities,
such as those above, were to be modeled adequately and

on a detailed basis by the LREPS project team.

The discrete-change events were conceptualized as
occurring at a fixed time or randomly as conditions in
the model dictated. Events were also conceptualized as
being processed chronologically and on a first-in, first-
Out (FIFO) basis. The designed events could then be
processed on a detailed day-to-day or week-to-week basis
dependent upon the conditions specified in the event sub-
programs and model input.

Since system entities were conceptualized as being
processed in discrete-event activities, programming sys-
tems for processing continuous-change, simulation models
were excluded from serious consideration. The excluded
computer systems included analog systems that treat the
processing of system entities on a continuous-flow basis
and digital systems that process system entities as con-
tinuous-flow rates on a discrete-change basis. The use
ofsnxfl1programming systems requires that system entities
be treated on a macro or aggregative basis rather than on

an individual basis as conceptualized in the LREPS system

44

model. If system processing procedures had been conceptu-
alized on a macro basis, then continuous-change simulation
languages would have been seriously considered.
Considering the above factors and programming lan-
guages that were reasonably available to Michigan State
University and which could process discrete events on both
a fixed- and/or variable-time basis, FORTRAN, GPSS,
SIMSCRIPT and GASP were seriously considered for computer-
izing LREPS. Each of these languages will be briefly dis-
cussed in reference to the selection criteria in Figure 10.
FORTRAN.--The first programming language considered
is a common general-purpose language called FORTRAN that
is not specifically structured to simulation models but
is scientifically oriented. Naylor mentions that the
programmer has the flexibility of being able to write
almost any subroutine that he may need for a particular
simulation plus he can tie the subroutines together by
using a main program and calling the specific subroutines
when they are needed.49 Although one gains much more
flexibility using a general-purpose language such as
FORTRAN, it requires more programming skill than some
of the other simulation languages. Using FORTRAN one
must be able to program many of the tasks that the simu-
lation languages already provide. Thus one can become
more involved in the programming rather than designing
the structure of the model. One must, however, remember
the availability of scientific subroutine packages that

are available for data generation and statistical anal-

ysis on most computer Operating systems.

45

Although FORTRAN has some definite disadvantages,
one must consider the fact that FORTRAN is a widely used
language with which many people are familiar. It is
relatively easy to learn if one has some mathematical
background. In fact, most universities are using
FORTRAN in their courses; thus, providing a large sup-
ply of available programmers that can assist in the
programming at a reasonable cost. Also many books have
been written on the use of FORTRAN which alleviates the
problem of poor documentation that occurs with the use
of some of the other simulation languages.

There are no special flowcharting symbols to be
used in programming FORTRAN simulations; however, many
computer manufacturers are now developing standard
flowcharting symbols for general programming. FORTRAN
does not offer any special simulation procedures but
one does enjoy very flexible formatting of output.
Again, this flexibility is gained only at the cost of
additional programming effort and time.

There are no logic checking routines built into
the language; however, the language does print error
diagnostics concerning FORTRAN rules Of programming.
Related to the lack of logic checking routines, there
are also no tracing routines to aid in debugging.

In reference to computer costs, FORTRAN programs
usually have small requirements for computer memory

during compilation and execution. However, this is

46

generally dependent upon the level of FORTRAN associated
with a particular computer operating system. For
instance, some FORTRAN languages have the ability to
manipulate packed words of computer memory in which more
than one piece of information can be put in one word.50
This level of FORTRAN is called EXTENDED FORTRAN.

Another aspect of computer cost is compilation and
execution time. One may experience high compilation times
using FORTRAN depending on the structure of the system
model and how frequently one may wish to change the
system structure. Fast execution times can be often
achieved, however, because the specific model activities
that have been programmed have not been restricted to
the rigid structures of simulation languages. Execution
times can also vary with the amount of information pack-
ing that has taken place.

FORTRAN is highly compatible among different com-
puter systems from small-scale to and including large-
scale systems and among different computer manufacturers.
However, one must realize that each manufacturer does
not have the same operating system. Depending on the
size of the simulation, the amount of special programming
that is done and the level of FORTRAN used, this highly
compatible feature can be very misleading. However, most
computer manufacturers are going to and stressing the

use of American Standards Association (ASA) FORTRAN.

47

As mentioned, this language is generally available
on most computer manufacturers' systems, thus there is no
serious limitation of small availability of computer
hardware. Concerning the present study, both Control
Data Corporation and International Business Machines
computers are available.

The last consideration is the applications to date
using the language. Naylor notes that FORTRAN has been
used for many specific applications to date in a wide
diversity of disciplines. This is primarily because of
its scientific orientation.51

§g§§.--The second language to be considered was
GPSS (General Purpose Systems Simulator) developed by
IBM.52 This language is primarily structured to schedul-
ing, waiting-line and other similar problems in which a
flow of transactions or individual entities over blocked-
time intervals are analyzed. Priorities from 0 to 7 can
be assigned to the transactions with up to eight para-

meters per transaction.53

The language is not as
detailed as FORTRAN but requires gaining a good familiar-
ity with the structured parts of the language. FORTRAN-
like statements are permitted in the program for alge-
braic computations on system state variables.54
Because the language has a special set of system
flowchart symbols which can be directly referenced in

the computer source program, the language provides not

only conceptual guidance in developing a computerized

48

model but also facilitates the development of the computer
model. The language also provides special forms for get-
ting the model computerized which also facilitates the
computerization task. The biggest advantage of this lan-
guage is the availability of simulation-defined and user-
defined concepts to aid the systems analyst.55
The language assumes that one does have some systems'
background plus a knowledge of FORTRAN or some other
general-purpose programming language. With this back-
ground plus the aid of good documentation and instruc-
tional material, the language is not too hard to learn.
However, as with any SOphisticated simulation language,
to realize the full potential of the language one must
use the language and learn its subtleties through con-
tinued use and under proper experienced supervision.
One shot deals about once a year would not allow one to
realize the full potential of this powerful language.
With a shortage of knowledgeable experienced GPSS pro-
grammers, programming costs would be expected to be
higher than using general-purpose language programmers.
Simulation procedures are available for aiding in
the initialization of system variables, generation of
data, handling of transactions on a blocked-time inter-
val, and writing of output records. The language also
allows one to stack a series of simulation cycles.
Simulation testing, validation and error-checking rou-

tines are available to aid the system analysts to get

49

the model running. The handling of transactions can be
based on a fixedror random-time interval (including zero)
dependent upon the conditions in the system or the activ-
ities jump to the next future event at which time all
possible activities must be reviewed.56
Computer times of compilation and execution are
generally faster than FORTRAN programs because GPSS
uses many efficient assembly—language subroutines. These
subroutines are readily available for the activities
desired. Because they do not have to go through the
translation from simulation language to a general-pur-
pose language to a computer machine language these com-
pilation times can be very fast. Also because expert
programmers have written the machine-language routines,
they are very efficient from the standpoints of execu-
tion times plus core and operating system utilization.
One of the main problems that one confronts with
using these very powerful languages is that GPSS, for
instance, requires at least a large-scale IBM 360 com-
puter system with large core plus three tape drives for
compilation and execution. In addition, GPSS specifi-
cally does not have the ability to pack variables as
one can do in FORTRAN and, therefore, a system model
of any complexity can require much core.57 The only way
packing can be handled is to write IBM 360 FAP assembly

routines to handle these activities. As has been

implied, GPSS is an IBM language that is only available

50

on large-scale systems. There are different ver-
sions of GPSS with the most powerful version, GPSS III,
available on the 360's only. The earlier versions of
GPSS are available on such machines as the IBM 7000
series.58 The ready availability of IBM computers,
however, makes this language a very attractive choice.
Assuming that one has available an analyst who is
knowledgeable of GPSS, it is easy to change a system
model for study of system behavior and for maintenance.
The applications to date have centered primarily in pro-
duction scheduling, waiting-line problems such as toll-
booth problems and in the simulation of computer operat-
ing systems. One of the main reasons why IBM develOped
the language was to aid in simulating time sharing

systems.

SIMSCRIPT.--The next language to be discussed is

 

SIMSCRIPT which is an "event oriented" language that is
applicable to many diverse simulation problems.59 The
SIMSCRIPT language is based upon a description of sys-
tems involving concepts denoted by entity, attribute,
set state and event.60 Rather than having to review
all possible activities that could take place at a cer-
tain point of simulated time, this language jumps to

the next imminent event which triggers a given activity.
This activity could also generate more variable-time

events or just be ended by the next event in the queue.

The language has many conceptual aids in getting a

51

system model computerized. The language is not as
detailed as FORTRAN but requires gaining a good famil-
iarity of the conceptual components of the language

to use it effectively. As in GPSS, FORTRAN-like state-
ments are permitted in the program for algebraic compu-
tations and data manipulation on system state variables.

The language, similar to GPSS, requires a system
background plus some programming experience with general-
purpose languages in order to learn and be able to use
effectively the basic, structural parts of the language.
The language has no special set of system flowchart
symbols but does have special coding forms that aid in
structuring and computerizing the model.

Simulation procedures are available for aiding in
the initialization of system variables, generation of
data, handling of event transactions on variable-time
intervals and perhaps the most flexible means of writ-
ing output reports of any of the high-level simulation

61,62
languages.

Special report forms allow the system
analyst to design many special reports. Also available
are simulation testing, validation and error-checking
routines. This language has more power than GPSS in
being able to pack words in core and possibly allow
more efficient program execution although GPSS may be
easier to implement.63 The language offers much power

from the standpoint of efficient core utilization plus

an event orientation that does not have to test all

52

possible activities at an instant of time. The language
also offers machine-coded subroutines to expedite the
compilation of the activities of the model. Compilation
and execution times are generally faster than FORTRAN
programs because of these available, efficient subrou-
tines.

The language is a RAND corporation language that is
available for computer systems of many different manufac-
turers such as IBM, CDC and BURROUGHS. Presently the
language is not available for the IBM 360 but is avail-
able on the IBM 7000 series systems. The language does
require a large-scale computer system for compilation
and execution. Computer hardware, a CDC 6500, is avail-
able at MSU for this language but it is not the most
SOphisticated level of SIMSCRIPT. Not only is it a
lower level of SIMSCRIPT but also the compiler is not
fully tested and reliable.

The availability of personnel who are experienced
with this language is very limited. As with GPSS, this
language requires that one use the language many times
in order to reap the full potential of the language.

The quality of documentation and instructional material
varies with the level of SIMSCRIPT that is implemented
on different systems. The later versions of the lan-
guage, as with GPSS, have good supporting materials.

SIMSCRIPT programs are relatively easy to change

for system maintenance and study given you have

53

knowledgeable personnel assisting in the system analysis.
SIMSCRIPT has been used for a wide range of problems
especially large-scale simulations that require efficient
core utilization plus fast computer execution times.

GASP.--The last language to be discussed is an
event-oriented language that is applicable to many,
diverse simulation problems. The language is called
GASP (General Activity Simulation Program) and centers
around a set of twenty-three FORTRAN-compiled subroutine
programs and function subprograms linked and organized
by a main program known as the GASP EXECUTIVE.64 The
language is a discrete-oriented language that provides
conceptual guidance in the development of the system
model. The language requires a knowledge of FORTRAN
and system concepts in order to program the model. The
language is easy to learn if one has some mathematical
background and systems and programming experience. Arith-
metic Operations, set operations and logical testing
are provided through user-written routines that are
related to the model's defined activities.

The language provides no special flowcharting
symbols for conceptualizing the model. There are,
however, special coding forms that have been devised to
aid in this conceptualization process. These forms are
related to the special simulation procedures provided
by the GASP subroutines for file maintenance, data

generation, input and output, automatic monitoring of

54

program variables and conditions for error detection and
debugging, selective tracing of program flows for dyna-
mic error debugging, and programmed dumping of system
variables.

The GASP subroutines plus the normally available
scientific subroutine packages that accompany most com-
puter operating systems allow one to do a number of
different types of simulation and non-simulation prob-
lems. Output formatting is still a problem for special
reports. The GASP system has available report summaries
of the historical information concerning the events and
entities passed through its files but there is no flexi-
bility in designing the format of these reports. Reports
of non-GASP arrays and constants still must be formatted
and wrote via a user-written subroutine. The simulation
language has available a subroutine for the user in which
he can specify these reports.

The GASP language has potentially small requirements
for storage during compilation and execution dependent
upon the expertise and experience of the programmers
doing the computerization. If packed variables and other
sophistications are used, one can develop a fairly effi-
cient program from the standpoint of core memory utiliza-
tion. The GASP simulation programs would possibly take
more time to compile and execute than other simulation lan-
guages because of the highly efficient, already developed
assembly-or machine-language subroutines that accompany
the other languages. The specific GASP subroutines are,

however, efficient and are very powerful when compared to

55

the user-written routines that could be very inefficient.
This again depends upon the level of sophistication
stressed in getting the model computerized. In summary,
by using the available GASP subroutines for the model,
one does get a more efficient program from the stand-
point of core memory utilization and running time than

if one had to write his own subroutines for the general
simulation activities mentioned above.

The language is highly compatible among different
computer systems for small scale-to and including large-
scale systems and among different computer manufacturers.65
The language has been written in ASA FORTRAN with as
little extensions to specific computer manufacturer
compilers as possible.

Given the FORTRAN basis of this language, it can be
implemented on any of the computer operating systems that
have available a FORTRAN compiler. Some modifications
would have to be made for scientific subroutines, such
as random-number generators, plus one would, no doubt,
experience the usual problems of getting a FORTRAN pro-
gram implemented on different manufacturers' machines
and even machines by the same computer manufacturers.
Nevertheless, it should be easily implemented.

Because the user has to write FORTRAN-based sub-
routines to model the activities of the system under
study, GASP programs usually require more detailed

changes in the program for studying system behavior and

56

for maintenance than other higher-level simulation lan-
guages. This again depends upon the stressed modularity
of the program and the number of computer subroutines
that are segmented in the overall program.

Large-and small-scale applications have taken place
in many areas because of the FORTRAN basis of the language
and its compatibility among installations. Also promoting
the use of the language is the availability of good docu-
mentation and instructional materials. The main reason it

has not been used more is the lack of publicity among users.

Selected Programming Language

 

After considering FORTRAN, GPSS, SIMSCRIPT and GASP,
the language that was selected to program LREPS was GASP.
The level of GASP chosen was the IIA stage that not only
incorporated integer attributes in its filing system but

66 Given that the

also floating point or real attributes.
system model is discrete oriented, anyone of the languages
could have been used for building a computer model of
LREPS. However, because GASP has already worked out the
programming details of many simulation activities it was
felt that to program the model in FORTRAN alone was waste-
ful. Therefore, FORTRAN was ruled out. Considering the
higher-level languages, SIMSCRIPT received the edge because
of its variable-time orientation toward the execution of
the model's activities. GPSS would seem to take more

execution time especially for a model that would be

simulating a ten-year planning horizon. SIMSCRIPT was

57

also appealing from the standpoint of its efficient utili-
zation of core memory considering the large amounts of
information that were to be handled. Conceptually, the
flowcharting assistance given by GPSS was also very
attractive. It was attractive if persons who were know-
ledgeable of the flowcharting procedures were available.
Related to this last statement was a very important prob-
lem concerning the lack of available personnel who were
knowledgeable or who had used SIMSCRIPT or GPSS. There
were a few people but they were not available at a
reasonable cost.

The level of programming skill for SIMSCRIPT and
GPSS was also greater than for GASP. Several students
in the business and engineering schools at MSU had used
GASP. Thus, extensive training of personnel to begin
the task of computerizing the model would not be neces-
sary. There were, however, regularly scheduled classes
off-campus at high cost where training in the use of
SIMSCRIPT or GPSS was offered. No classes at MSU offered
instructions in the use of SIMSCRIPT or GPSS. GASP,
however, was taught in several classes and schools.

All three languages offered assistance in simula-
tion procedures associated with initial values, data
generation and manipulation, time-flow mechanisms, out-
put assistance and stacking of a series of cycles. The

languages also assisted in debugging and error tracing.

58

These attractive aspects of simulation languages again
supported the decision not to program the model in FORTRAN
alone.

There were tradeoffs back and forth between the lan-
guages concerning computer costs of compilation and execu-
tion. The main cost of running GPSS at MSU was that the
LREPS project team would most likely have to pay the high
costs and receive low priority of computer run testing on
MSU's administrative IBM 360-40 assuming a GPSS compiler
could be readily obtained. At the time MSU did not have
a GPSS compiler. The University of Michigan's IBM 360-67
was available but in this case the use of the computer
would result in large travel expenses. GPSS had not yet
been implemented on remote terminals to debug and test
routines and to use the model after it had been operation-
alized.

All of the languages have facilitating features for
changing the system model although GPSS and SIMSCRIPT have
the advantage over GASP. SIMSCRIPT has a very important
advantage over both GASP and GPSS in report generation
because of its flexible report generator. Applications
to date have been many and varied and offer little basis
for a good comparison of the three languages.

Three main factors concerning the use of SIMSCRIPT
were questionable. The first factor was the lack of a
reliable compiler and good instructional material for

SIMSCRIPT 1.5 at MSU. The second factor, related to the

59

first, is the lack of a compiler at MSU for SIMSCRIPT II,

67 The last

the latest and most sophisticated version.
and, perhaps, most important factor was the very limited
supply of personnel knowledgeable in the use of SIMSCRIPT.
None of the LREPS project team members had ever used
SIMSCRIPT for a modeling application. The only attempt
was the testing of a sample problem for the SIMSCRIPT 1.5
compiler. The sample problem was never successfully
tested since the MSU compiler for the CDC 6500 was not
Operational.
The final decision to use GASP IIA was based on six
factors:
1) The high compatibility of the FORTRAN-
based, simulation language among computer
operating systems. The lastest, most
powerful versions of GPSS and SIMSCRIPT
only have compilers for International
Business Machines (IBM) computers.
2) The minimization of the cost of using
the model in different geographic loca-
tions if the model could be designed to
be compatible among different computer
Operating systems.
3) The good familiarity of the LREPS project
team with the general-purpose programming

language FORTRAN.

60

4) The ready availability of SOphisticated
FORTRAN programming personnel, via MSU's
student body, at a reasonable cost.

5) The ready availability of MSU's research
computer center to Operationalize LREPS.

Costly time delays of not having a com-
puter readily available would, therefore,
be avoided. It should also be noted that
the university research contract did not
restrict the location at which the model
could be operationalized but did restrict
the amount of time and money that could
be used in developing LREPS.

6) GASP was the only discrete-event simula-
tion language operational on MSU's CDC 6500.

If SIMSCRIPT II had been operational at MSU,
then it would have received major considera-
tion as the predominant computer program-
ming language. The possible use of this
language is an open area of research.

In relation to factors five and six, several authors
support the great importance of the ready availability of
Cmmguter hardware. Tocher mentions this factor when he
diW3usses the fact that there are many important features
0f each simulation language but ". . . it remains a sad
faCt that the choice will most likely be made by the type

68

Ofmachine available to him." Teichroew and Lubin

61

predict that the time will come when the languages will be
on most computers and this will not be such a problem to
potential users.69 Until such time, the ready availability

of computer hardware and the languages operationalized on

the hardware cannot be underemphasized.

CHAPTER II--FOOTNOTES

1T. H. Naylor, J. L. Balintfy, D. S. Burdick and
Kong Chu, Computer Simulation Techniques (N. Y., London,
Sydney: John Wiley and Sons, Inc., 1968), pp. 10-11.

2

 

Ibid., pp. 239-240.

3Daniel Teichroew and J. F. Lubin, "Computer Simu-
lation--Discussion of Techniques and Comparisons of Lan-
guages," Communications ACM, Vol. 10 (Oct., 1966), pp.
725-726.

4Ibid., p. 731.

5Ibid., p. 726.

 

6H. S. Krasnow and R. A. Merikallio, "The Past,
Present and Future of General Simulation Languages,"
Management Science, Vol. II (Nov., 1964), pp. 254-267.

7K. D. Tocher, "Review of Simulation Languages,"
Operations Research Quarterly, Vol. 16 (June, 1965),
p. 192.

 

 

8Naylor, Balintfy, Burdick and Chu, p. 241.

9Howard S. Krasnow,_"Computer Languages of System
Simulation," Digital Computer User's Handbook, ed. by
Melvin Klerer and Granino Korn (N. Y.: McGraw Hill Book
CO., 1967), Section I, p. 261.

10Naylor, Balintfy, Burdick and Chu, p. 241.

llKrasnow and Merikallio, p. 254.

12P. J. Kiviat and A. A. B. Pritsker, Simulation
With GASP II: A FORTRAN Based Simulation Language
(Englewood Cliffs, N. J.: Prentice-HalT, Inc., 1969),
pp. 1-21.

lBKrasnow, p. 275.

 

 

l4Naylor, Balintfy, Burdick and Chu, p. 241.

62

63

15

Krasnow and Merikallio, p.

254.

6Krasnow and Merikallio, p. 259.

l7Teichroew and Lubin, p.

18Naylor, Balintfy, Burdick and Chu,

19Teichroew and Lubin, p.

20

Teichroew and Lubin, p.

lTeichroew and Lubin,

22Krasnow,

p.

p. 261.

23

4Teichroew and Lubin, p.
25

26

27Teichroew and Lubin, p.

28

Teichroew and Lubin, p.

29Teichroew and Lubin, p.

JONaylor, Balintfy, Burdick and Chu,

31Krasnow and Merikallio,

32D.

Naylor, Balintfy, Burdick and Chu,

Naylor, Balintfy, Burdick and Chu,

Naylor, Balintfy, Burdick and Chu,

Teichroew, T. D. Truitt,

737.

pp. 240-241.
732.

738.

738.

241.
732.

p. 241.
p. 241.
732.

731.

732.

241.

p. 254.

and J. F. Lubin,

"Discussion of Computer Simulation Techniques and Compari-
son of Languages," Simulation, Vol. 9 (Oct., 1967), p. 244.

 

33Teichroew and Lubin, p.

4Krasnow and Merikallio,

35

Krasnow, 263-264.

PP-

36Krasnow and Merikallio,

37Teichroew and Lubin, p.
8Krasnow, p. 276.
39

Krasnow and Merikallio,

40Teichroew and Lubin, p.

732.

p. 238.

pp. 265-267.
733.

p. 238.

730.

64

41Teichroew and Lubin, p. 733.
42Naylor, Balintfy, Burdick and Chu, p. 241.
3Teichroew and Lubin, p. 733.

44Naylor, Balintfy, Burdick and Chu, p. 241.

45Krasnow and Merikallio, p. 257.

46Krasnow, p. 261.
47Naylor, Balintfy, Burdick and Chu, p. 241.
48Teichroew and Lubin, p. 726.

49Naylor, Balintfy, Burdick and Chu, pp. 242-243.

50Teichroew and Lubin, p. 738.

51Naylor, Balintfy, Burdick and Chu, p. 242.

52R. Efron and G. Gordon, "A General Purpose Digital
Simulation-Description," IBM Systems Journal (Vol. 3,
No. l, 1964), p. 57.

53

 

Naylor, Balintfy, Burdick and Chu, p. 249.
54Naylor, Balintfy, Burdick and Chu, p. 248.

5Krasnow and Merikallio, p. 256.

56Teichroew and Lubin, p. 731.

57Teichroew and Lubin, p. 733.

8Teichroew and Lubin, p. 726.

59H. Markowitz, B. Hausner and M. Karr, SIMSCRIPT:
A Simulation Programming Language (Englewood Cliffs, N. J.:
Prentice-Hall, Inc., 1963).

60

 

Naylor, Balintfy, Burdick and Chu, p. 279.

61Krasnow, p. 276.

62

Teichroew and Lubin, . 739.

63

Teichroew and Lubin, . 728.

P
P

64 . . .

KlVlat and Pritsker, p. 18.
P

65

Teichroew and Lubin, . 726.

65

66Kiviat and Pritsker, pp. 258-263.

67P. J. Kiviat, R. Villanueva, and H. M. Markowitz,
SIMSCRIPT II (Englewood Cliffs, N. J.: Prentice-Hall, Inc.,
1968).

68

 

Tocher, p. 191.

69Teichroew and Lubin, p. 738.

CHAPTER III

THE DEMAND AND ENVIRONMENT SUBSYSTEM

Inputs, Outputs and Data Base Requirements

 

Referring to Figure 2 in Chapter I, the inputs into
the D&E subsystem are broadly defined as the sales fore-
cast, customer orders, customer mix, product mix,
decision rules and management parameters. These broad
categories of inputs were manipulated within the D&E
subsystem to produce allocated DU, DC and regional simu-
lated sales. Allocated customer orders served as the
inputs into the OPS subsystem to be accounted for at the
DU and DC stages of the model. In addition, the effect
of the allocated customer orders were processed at the
MCC stage plus additional sales and service information
was prepared and accounted for at all levels of the
model by the OPS subsystem.

The above D&E inputs and outputs were not Specific
enough to computer program the activities associated
with their manipulation and production. The specific
inputs into the D&E subsystem and the key endogenous

variables associated with the subsystem activities are

66

67

noted in Appendix 1. All common data base variables
marked with "U" or "S" under the column labeled D&E
represent the variables that were used or altered within
the system. The endogenous variables, indicated by an
"N" under the TYPE column, were the basis for the derived
outputs of this subsystem. The exogenous variables are
those variables that must be inputted into the D&E from
its supporting data system through the M&C gateway. The
"U," endogenous variables represented those variables
that are set in one of the other Operating subsystems of
LREPS. As was mentioned in Chapter II, the only exogen-
ous variables not specifically identified as coming
through the M&C gateway into the common data base were
those variables associated with the order file.

The organization of this chapter focuses first on
the activities in the operating system of LREPS that
processed its related inputs, both exogenous and from
the other subsystems, and developed the outputs for the
OPS subsystem. This first section is called the
OPERATING SYSTEM. The specific activities associated
with the D&E subsystem are:

l) DSQGEN associated with the generation of
the domestic daily sales dollar quota.

2) SLSPRC associated with the generation of
the allocated customer orders for the DU's
in the geographic area of the DC presently
being processed.
The above activities happened on a daily basis. None of

the D&E activities happened only on a monthly or quarterly

68

basis, although more sophisticated and additional routines
could have been programmed to take place on other than
a daily basis.

In relation to the daily LREPS activities, the
pertinent variables are defined by their respective data
base name, column number, if any, plus a brief description
of the variable. These pertinent variables are also
classified in the routine's system flowchart. The vari-
ables are classified on the basis of inputs which were
defined as the LREPS common data base variables used in
the routine, "local" key endogenous variables set and
used only within one routine, "subsystem" common endo-
genous variables set and used by more than one routine
in the entire subsystem, and output variables which were
LREPS common data base variables set or altered in the
routine.

Each of the Specific LREPS D&E modelling activities
are discussed in detail by relating to the respective
computer system flowchart and block diagram. A detailed
activity review is necessary to clarify the activity's
logical location within a certain computer program or
subprogram. In addition, the implications for improve-
ment plus the results of testing and calibration for
the more complicated activities are discussed.

After the OPERATING SYSTEM, the next section of
this chapter is the D&E's SUPPORTING DATA SYSTEM. This

section presents the D&E computer activities that aided

69

in analyzing and preparing exogenous variables for the
operating system. The supporting data system computer
programs are:
1) Selection of sample, actual invoices
2) Analysis of the sampled invoices
3) Analysis of the product items in the sampled
invoices
4) Analysis of the product items based on
annual sales
5) Development of a basis for calculating road
distances
6) Sales potential correlation analysis
7) Generation of DU data
8) Selection, agglomeration and variable pro-
jection of DU's
9) Generation of the customer order file
For each program a logical block diagram of activi-
ties, the programming language(s) used, the variables or
information associated with the program plus any peculiar
programming problems or techniques are discussed. Impli-
cations for SOphistication are also presented where it

was deemed necessary because of model or program complexity.

Operating System

 

Referring to Figures 11 to 14, the activities asso-
ciated with the Operating system's D&E subsystem are
described graphically. In the comments section of the

block diagrams, the activities associated with a particular

noabawud>, :oapcuocoo cacao noaum haduosu.HH ousmam

326 2&5 s23 do 53:810..-.NA can:

3E3: 226 fig 8. c.3331

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

zmpemm
one
no:
ascend» vowmavoa a an own ovuuosoo QA<U mwmwm
cacao «aflun thco awn Mqua
0:390." :oapuuocow scan.» v0.8.2.0: @ sol-co meazmo
mmqdem<> maozmooozm Hum 4\\)/47
0
7
DPS": BE. p.33 3 53.x a
Adoh\ahcvxuos uaunaaadn mo .02 mwnxzz
. 8a 89.388 08 so 25 882.
ahavxuo: vouaasndu uo hopes: zoo pauoouou udHHov oavuosou webmmmae f
an uova>fiu puuoouou Huscsaauusauncoo a an own ovcHSOHdo oq<o
» onemHmomwo mz<z
33.5 8.5.8: 3 33¢ PE. .2 o: 8. :85 g 2 new

cvosv udaaoo acadu caucuses haddv ovuuosom on osdvsom

71

ocaugau uaa..oooLL .oacn Luann 00...n~ oLuuLL
Lu«>«ao- an... L4Haa 0» nuuuom

33 55302.3 0.09
0033073 03 00000.1 3 3.50.- BYLOILEO mac 3 3:3

non-000.3 on 3 on
El. Lou 33 L0?! 3 96.5 600.3 D0: 223: saw-m

.33 8326 L0?! 50 £963 93

0.00.3 L020 30:0 Lou :03
on 603000.30 3 003 3 00.70 033300 03 La

8 :43
Lou g .603 L020 3000.3 3 05302 mac 3 x03

300.3 .3050 L0.» 0.30.3 30 £9.03 33
an a on was»
Lou Leona Annuapducd uaoooun o» ocaaaou mac 00 scan

3 .3305 30300 .33 3.326 Lou so
uaan>nfi LL .oALu Lu-aansu .«ga LuL =0 goofing LH-uucae

800.3 Lola-.6 Lou 0.30.00 :3 0-000Lm

13.1.5600 0:. 310030 03: com: 0003 .090 3 1:00
.8 :3 000a £303 3 2030233 x003 LOP—0 ago:

axooan L0 300
0.38326 03 IPC x003 L093 :0 30300 3:025.

ocaasou coduooaou zoofin LovLo

. Lou-disco: L030 u:-
33 L0a326 3 003090.20 0010 L0 «56:- 3016.70

0&3 LOIS-.6 Land. ha :1- 30ng

0:» L003 ELL 00.3.33 :00.» 00: 9.0L» L020 3 00m

.3301.“ 5303.300- 0300 Ed
uncoOLou L0 203056 0 .0 .300 03:23- uo 33.6.70

9300000.:— 0010 .73 on Lou 0:309— m3

 

0033...; unannouoLm moanm 11.82.59 9:62

 

 

 

mama», “0305085 hm:

nLovLo Logunso Mo 96.5 .3810
03:00.5 $53 x003 L360 326 "58$
30.1.0003 MESA L020 326 95H
.320 Lou “.0303: and: E 3229"
mSmSO
/ 301.0 L430” .3: 0300le bndco Omd
98/. C030
-t. nomaoooua Sudan ads: nuance ozsoH
53m 00:30.3 3.00.3 LopLo undo L0 Lon-5.: 83m":
693 08$ «.26 Leo 3?po L020 «0 Lon-5.2 mfimu
EEC... Locuvos 0.00.3 L075 50
.w !_ Lou-#:560- Ldzou :10 326 u<m§
. 63.60:: 3:00 00H: 326 .3950
53m tonuOOOLa x53 85» 02.6 math;
5 :2. 2.3.35. 8 938
.3. an _ 703

 

 

n.03upd wouzmdo: as L0 50m AncmHua
”Ovulu Sowudofihdgfl eOHlm fidvag
on c« ..;e L0 Laban: Anvmuoo

Lmucdoa on 00330.75 8:5

raped pcsgmdo: o>aundaaso Akvso

2a pocmdan- ta Loose

8.333.: .3833... 1325 :39

03.000060 993 Foo uo Lanna: H.309 man:

093 «36 Lee 3.003 30.5 53.8

3323.3.“ fin .3500 326 adage; 95.50

33000.3 93!» couwom 028::

«L020 3.3326 Lo ngLo 5595

00:000.: “Each 0100 on 73:33. 528w

“0030003 9:09 on 003307.: ozooH
95%:

ZCMEHEUEQ m5:

 

 

820 .88
me§<
a. whaao

 

 

72

saubprogram are briefly discussed. In addition to the
kilock diagram a discussion of the programming language(s)
Insed, the LREPS variables associated with the activity,
;p]JJs the identification of any peculiar programming
txechniques or serious programming problems are presented
for each subprogram.

The first major subprogram of the D&E is the genera-
thon of the domestic daily sales dollar quota. The vari-
afloles associated with this subprogram are identified in
Ifiigure 11. Three of the variables are exogenous. TDSFLG
arui NWKDYS were inputted at the beginning of the cycle.
frDSFU the annual domestic sales dollar forecast, was
iJuputted annually. DSQ is the generated daily sales
quota which can be either a constant, a random variate,

a trend modified variate, a seasoned variate or a variate
based on some combination of the above. The logical
activities associated with this subprOgram are presented
in Figure 12. This FORTRAN subprogram developed the
base figure which was allocated to the in-solution dis-
'tribution centers.

The other major component associated with the D&E
is the normal processing of the simulated sales for each
in-solution DC. There were a number of important activ-
ities associated with this subprogram. Each of the
acRLivities will be discussed in reference to the block
diagram in Figure 14. The variables associated with this

subprogram are listed in total in Figure 13.

73

Referring to Figure 14, Activity Block 1 was con-
cerned with the generation of the DC's simulated sales.
The variables associated with this activity were DSQ
from the above discussed subprogram, DCIS(4) from the
M&C activity associated with the develOpment of a DC's
sales forecast modification factor, DCIS(S) from the
M&C subprogram associated with developing DC-DU related
information, IDCNO from the M&C daily fixed-time event
activity that specified the DC presently being processed,
and finally DCSALS which was the output from this activ-
ity. This activity was programmed in FORTRAN according
to the math model specifications.

Block 2 is a routine that was programmed in assem-
bly language to enable the computer model to buffer the
order file into the computer program for the operating
system. Buffering enabled us to overlap the inputting
of information while processing the remaining activities
associated with the DC being processed. Presently this
activity uses a very simple buffering procedure. Later
a more sophisticated buffering procedure could be
developed that would enable LREPS to process the order
file tape at literally tape speed on the CDC 6500.

The variables associated with this buffering activ-
ity were the order group variables, ORDGRP(1) through
ORDGRP(4), for all order blocks. Given that the deci-
sion had been made to work with summarized blocks of,

for instance, ten or less orders, a group of order

74

blocks was buffered in for each in-solution DC each day.
An order group, which will be discussed in more detail

in the SUPPORTING DATA SYSTEM of this chapter, was com-
posed of a set number of order blocks. The type of order
blocks, however, could vary between cycles. In one cycle,
four blocks might have been for a certain customer type
while six blocks were for another type. In another cycle,
the block splits might have been four, four and two among
customer types.

The total number of orders per order group was set
to furnish the larger size DC's with the average number
orders that they would normally process in a day. The
smaller DC's would use only the required number of order
blocks that they needed to meet their daily sales alloca-
tion. The usage of the order group will become clearer
as the activities associated with this subprogram are
developed in greater detail.

The next activity, Block 3, was programmed in FORTRAN.
The output of this activity was the amount of sales to be
allocated to a given customer type within the geographic
area of the DC and region being processed. The activity
also cleared an accumulator that enabled us to know when
we reached our allocation. The variables associated with
this activity were DCSALS from Block 1, CSPLTP which was an
exogenous input from the D&E supporting data system,
could be changed annually and specified the percentage of

sales that the customer type being processed was to get

75

from the DC's total sales allocation, IREGNO which was
set in the M&C daily event, ICTYPE, CSTSAL and CSTSAC
which were set in this block and outputted to the follow-
ing activities.

Block 4 was the random selection of one of the
order blocks for a given customer type from the DC's
order group. This activity was programmed in FORTRAN
and used a pseudo-random generator called RANF as the
basis for selecting a block. RANF generated a pseudo-
random number based on a 0,1 uniform probability distri-
bution. The endogenous variables associated with this
activity were IBLOCK which Specified the block that was
randomly selected, IBLKS that denoted how many blocks
had been allocated for this customer type, IPBLKS which
told how many of the past customer blocks had been pro-
cessed and ICTYPE which identified the customer type
being processed. The one exogenous input was the
vector variable CSTBLK which specified the number of
blocks per customer type for all specified major custo-
mers. CSTBLK was set cyclically.

Activity Block 5 was associated with what was called
an order block modifier. This modifier allowed the com-
puter model to approximate very closely the allocated
sales for a customer type. This routine modified a given
order block's contents if the order block's total dollar
sales were greater than the difference between the allo-

cated customer sales and the sales dollars already

76

accounted for by previous customer orders. The variables
associated with the activity were OBM which contained the
order block modifier, CSTSAL and CSTSAC from Block 3,
ORDGRP(l) which is an exogenous input from the order file
and an order block's ORDGRP(l) through ORDGRP(4) if the
contents of the order block must be modified. This
activity was also programmed in FORTRAN.

Block 6 dealt with the random selection of a DU
within the DC's geographic area of responsibility. A
small function, FORTRAN subprogram was developed to
accomplish the random selection of a DU. The function
was essentially based upon a Monte Carlo selection pro-
cedure. The basis for the Monte Carlo selection was
the DU's weighted indices for sales allocation. The
weighted indices for all DU's in a DC area were trans-
formed into a cumulative basis with which a random number,
generated from RANF, was used to select randomly the DU
that was to receive the current, allocated customer order.

After selecting the DU, one additional test was
performed. If the selected DU had certain special cus-
tomers given the Special customer type was being pro-
cessed, then the DU was acceptable. If unacceptable,
another DU was selected. This cycling procedure continued
until an acceptable DU was selected.

The variables associated with these activities were
IDUNO and IDUNOl which were concerned with the DU being

processed, NDUS which was the total number of DU's being

77

processed, DU(l) which specified if a certain DU had any
Special customers, DU(6), DU(7), DU(8), DCIS(Z), DCIS(3),
DCIS(S) which were the basis for the random selection of

a DU and were set in the M&C subprogram associated with
DC-DU link information, and IDCNO which was set in the

M&C event activity associated with normal daily activities.

Block 6 could be the subject of further sophistica-
tion that considered other factors besides a DU'S weighted
index. Distance, past sales, past service levels and
reliability plus other variables at a DU stage could be
used as separate or joint bases of random selection.

Block 7 was the means of joining the D&E subsystem
with the OPS subsystem. The OPS subsystem has a sub-
program called INDORD that processes the allocated cus-
tomer order by accounting for its dollars and weight at
the DU level. This OPS subsystem routine, which also
generated the required service times, will be discussed
in detail in the next chapter.

Block 8 is a FORTRAN activity to check if all
orders in an order block had been processed and allocated.
If all orders had not been processed, another DU was
selected and an order allocated to it. This activity
used the endogenous variable IORD which identified how
many orders had been processed out of the total number
in the block.

The next block enabled the OPS subsystem to process,

at the DC level, the product detail and all summarized

78

sales information of the order block whose dollars and
weight had just been allocated to the selected demand
units. This OPS subprogram, called ORDSUM, will also be
discussed in detail in the next chapter.

Blocks 10 and ll were used to check the amount of
dollar sales accumulated for the customer type being
processed against its amount of allocated sales. If the
sales dollars accumulated were not within a half percent
of the allocation, then another order block had to be
randomly selected. If the sales allocation had been
attained, then the subprogram went on to the next activ-
ity block. These blocks are FORTRAN activities which
use the endogenous variables CSTSAC, CSTSAL and ICTYPE
and the exogenous variable ORDGRP(l) from the order file.

Block 12 was the activity that initiated the read-
ing of another order group for the next DC to be pro-
cessed. The activity was an assembly routine that used
all the variables in ORDGRP. This activity could also
be sophisticated along with the earlier mentioned buffer-
ing activity in Block 2.

Block 13 was the connection to the OPS subsystem
associated with the processing of the DC end-of-day
activities. These activities were processed while a new
order group was read. This subprogram, called DCEODAY,
will be discussed in detail in the next chapter.

Block 14 was a return to the M&C daily event that
called this normal sales processing routine for each

processed DC.

79

Supporting Data System

 

Each of the following computer activities is
identified and discussed within the framework of the
LREPS D&E Supporting Data System flowcharts.l The non-
computer activities have not been discussed unless addi-
tional understanding of a computer activity was gained
by describing briefly a related, non-computer activity.

The supporting computer programs are described by
presenting a block diagram of the logical activities
taking place within the program, the programming language(s)
that were used, the operating system exogenous variables
that are directly or indirectly associated with the pro-
gram, other information associated with the program plus
any peculiar programming techniques or problems.

Figure 15 identifies the activities associated with
the selection of sample invoices from a firm's annual
invoice file. This program fits within the framework of
determining a firm's major customer types. Preliminary
analysis of annual data had pointed out possible major
customer types. Based on a stratified random sample,
which is indicated in Blocks 1 to 3 in Figure 15,
additional analysis was used to support the initial cus-
tomer type findings. Block 4 was the pulling of the
selected invoices from the annual file. Block 5 was the
preparation of the "Sampled Invoice" magnetic tape.

The Specific input information associated with

these activities were the invoice variables that were

 

(ENERNTE
PMNDOM
NOS

 

 

 

n¥

 

PULL
IWWHCES

 

_.2-
__.3.

 

80

Selection of sample invoices from annual invoice file

Select a random sample from each of the present DC's invoice
files

Select the above sample stratified on selected months

Generate invoice numbers to be selected from present DC-
monthly files

Loop through all months to be sampled

LoOp through present DC orders

Pull invoices for the selected major customer types

Prepare the ”Sampled Invoice" tape

End of activities

Figure 15.--Selection of Sample Invoices

81

split between the line item detail that contained product
information and the invoice summary data that contained
distribution center identification, customer type identi-
fication, invoice number, geographic identification,
invoice sales summaries, and the shipment dispatch date.
An additional input into the selection of invoices was
the random numbers generated for the specific invoices

to be selected.

The random numbers were generated from a pseudo-
random number generator that was available on a time-
shared computing system. The preparation of the "Sampled
Invoice" tape was an assembly card-to-tape routine. The
output of this program was the randomly selected invoices
with all the invoice detail described above. The operat-
ing system exogenous variables affected by this routine
was CSTBLK, CSPLTP and ORDGRP.

After the sample invoices had been selected, the
analysis of these invoices followed the block diagram
in Figure 16. This "Sampled Invoice Analysis" actually
supported several areas of analysis. Block 1 analyzed

the invoice summary information at a total level to

 

identify the overall sample means, standard deviations,
number of sample points and range of values for each
item in the invoice sales summary records. Blocks 2 to
6 were concerned with the generation of the above sta-
tistical information based on a major sort of a firm's

sales regions and on minor sorts of customer type and

82

and month. Thus this analysis supported the major customer
analysis. Books 10 to 11 analyzed only the effect of
monthly sales across the nation. This last analysis was

to support the daily sales analysis, regional analysis and
domestic daily sales analysis.

Based on the information generated from this FORTRAN
program, decisions were made concerning different areas of
supporting systems analysis. The output was only printed
and subjected to manual examination. The operating system
variables affected by this program are CSTBLK, CSPLTP and
TDSFLG.

In analyzing a firm's product items, two supporting
system programs were designed. The first program analyzed
the product item detail based on the sampled invoices.

The line item detail records of the "Sampled Invoice"
tape were analyzed in the sequence of the logical activ-
ities Shown in Figure 17. A separate listing for each
type of sales information was prepared which Showed the
rank, the absolute and cumulative percentages of total
sales per product in the tape. An additional listing
showed the frequency with which each product appeared in
the sample invoices.

Figure 18 shows the activities associated with the
second computer program involved in the product item
analysis. The basis for this second program was an analysis
of a firm's total annual product sales. The input into the
program was a punched card for each product that contained

different sales information. A separate listing for each

83

a 62:33233 33H 838.5--.2 2%:

nanhadca no ucm

one» ooao>na one
:« pontoon: nova an acesveuu so: wcwzosu «honey 0:» oueooum

ovoo vosvoun no women one: «Ozone 23 tom

coaudlhousa mean» no mocha Han smacks» moo;

euaanoa nova convene oudaeum

nowuaahouca none»
nouaanlsooe co panda gecko mafiucoonov :« mica“ uosvouo on» whom

oeueoooua
unwon cease we cahu oz» you sodas-Louau scans on» ouaHSIsuo<

oohv node. zone you schemes loud uosuouo anemone

cane :oo«o>:H uoanicm: no ocean uaehaacu loud acoqum

3:433 coach—H voannemuaoa 0.33m

manna-co uo ecu

haze uaflsuou hH£QCOI oudaoum

unrepxaoun hose: 0: saw: ndnhauca hanunoa how easy whom

Laces co crepxaoun hocws saw: auasmou Losounso endaoum

acaovxeoun pecan on cue: nuasnou Losoanso haaoauun oudaoum

pooh no
anacos an chovxdoun nonas new: nanthce LoaouuSo you one» whom

29:0:
use uesoanso co nanouxeoun socai new: meanest Hocoamou oudaeum

 

 

yeah we scene: so crocxaoap hose: new: nuasnou Hocoamou oudQOhm
mausmmm
mma<m
.n mm<mwmm

 

 

 

coho Lelounso co szovxdeun Logan new: uuHShoa Hdcowmou ohdaoum

 

ectopxaoun Lonaa on new: nuasueu Hoseameu ominoum

 

 

use» no unucofl use onhu
uosounso co ouuon hoses saw: edema-ca aqcowmou you coca when

0
H

 

pm<km acaovxdoun
nonas 0: cu“: can-co ouoaaloo you uuHsuou ooao>ca oueooum

OHau ovaobca voanldn uo aanhHac<

.ae

 

$920:
mm<mmmm

 

 

20:

.0“ exam

.m

.n

 

 

mkzox
Ikmao
mm<mwmm

 

 

Fmau
mm<mmmm

 

 

emso

.6 atom

 

 

maze:
embolomx
mm<mmxm

 

 

:9202
team
mm<mmmm

 

 

Fmao
luwm
mmdmmmm

 

umm
mm<dwmm

 

 

 

Qmm
.N bmom

 

whasmmm

mm<mwmm

 

 

 

pm<9m

84

type of sales information was prepared that showed the
rank, the absolute and cumulative percentages of annual
sales per product.

Both of these programs in the product item analysis
were programmed using FORTRAN. The output listings from
the runs were used in preparing the exogenous inputs
TPDEM(2), ITNSP, ITNPC, PRCT(2), PRCT(3), PRCT(4), CGSCS,
CUBCS, WTCU. These operating system inputs were asso-
ciated with the tracked products that would be used for
inventory management, control and costing analyses plus
provide some of the basis for the generation of pseudo—
customer orders. Each of these areas of analysis will
be discussed in more detail later. New product and dif-
ferent order characteristic information were also merged
with the results of this analysis.

Figure 19 identifies the logical activities of a
program called the "Distance Check" routine. Given that
the basis for a demand unit had been selected, a program
was needed to check out a routine for calculating the
road distances between the hub cities of these DU‘s.

A routine for calculating the Spherical, arc distances
between two points was available and a road conversion
factor was needed.2 The program thus served two purposes.
One was to generate a good road conversion factor and
the other was to generate road distances for a comparison

to actual distances.

 

 

PREPARE

 

 

 

 

 

 

 

 

DIST'S

 

 

 

é,

 

 

FACTOR

 

 

 

 

855

Product itu analysis based on annual sales

Prepare product itaa.repcrts for each sales type

Sort the annual sales information for each product in
descending order

Prepare product item results

Loop through all types of sales information

End of analysis

Figure 18.--Product Item Analysis-No. 2

Distance check routine based on a sample of DU points

Use a range of highway conversion factors
Process all combinations of DU sample points

Calculate the road distance between selected two sample points

Loop through all DU combinations

Loop through alternative road conversion factors

Select best read conversion factor by comparing calculated
to actual road distances for saaple DU combinations

End of analysis

Figure l9.--Distance Check Routine

86

The input into this FORTRAN program was a punched
card containing the latitude and longitude for each sample
DU'S hub city, a card deck of actual road distances
between the sample DU'S, and a card Specifying the range
of road conversion factors to be considered. The output
included the best road conversion factor plus the standard
error between actual and calculated road distances and
the array of calculated road distances for the selected
conversion factor. The exogenous variables affected by
this routine are the rectangular, converted X and Y
coordinates of the DU's and of the potential DC's latitudes
and longitudes. Specifically, the variables are DU(2),
DU(3), DCP(l), and DCP(Z).

Figure 20 identifies the use of a system library,
statistical program for doing univariate correlation anal-
ysis. The purpose of this program was to analyze the
relationship between a firm's sales and alternative
independent variables. The card input to this program
was composed of one card for each of the firm's geographic,
sales control areas. Each card contained geographic
identification information, annual firm sales and the
relevant, alternative independent variables.

The printed output of the computer run contained the
selected independent variables and the correlation coeffi-
cients between the firm's sales and the independent vari-
ables which were significant at the selected level of

statistical significance.

87

The operating system exogenous variables Specifi-
cally affected by this program were DU(4), the weighted
index of DU sales potential, and DCIS(S), the basis for
DC sales potential.

Figure 21 identifies a FORTRAN program that was
used to generate the basic information needed at a DU
level. The input into this program was sourced from
three different areas. The first source of information
was customer information summarized for the selected,
basic demand units. Such information as the DU identi-
fying code, summarized sales information, number of
major customer types plus the number of direct competi-
tors was compiled and summarized at the DU level.

The second source of information was DU identifi-
cation information. Such items of information as the
DU identifying code, the DU's hub city for denoting the
point of demand concentration, the DU's latitude and
longitude, the type of DU--domestic or non-domestic,
and the DU agglomeration basis to an even further reduced
number of DU's. This last piece of information was con-
cerned with the reduction of counties to groups of coun—
ties, or zip sectional center areas to a reduced number
of geographic areas. This reduced level of detail, if
possible, allowed more efficient computer processing
times.

The third source of information was the indepen-

dent variable information. This source of information

 

(SW)

 

1.
PERFORM
ANALISIS

_.2-

SELECT
VRR'S

 

 

 

 

 

 

 

 

 

 

(SW)

 

IRITIALIZE
RUN

 

 

 

 

MERGE
DNTA

 

 

GENERATE 3'
LDD'L
om

 

 

 

 

 

MERGED
RESUUTS

6.
DU
TAPE

Cm)

 

 

 

 

88

Correlation analysis based on alternative independent
variables and firm sales

Process each alternative independent variable

Perform correlation analysis between firm's sales and the
alternative independent variable

Loop through all independent variables

Select independent variable(s) with significant correlation
coefficients

End of analysis

Figure 20.--Correlation Analysis

Routine to merge and generate DU internal firm and environ-
mental data

Initialise variables and arrays

Process all information for each customer demand unit

Merge firm and external environmental data

Generate additional summary and statistical information

Loop through all customer demand units

Write merged customer results based on DU's

Develop DU tape

End of analysis

Figure 21.--DU Data Generator

89

had a DU identifying code and the selected independent
variables' base year totals. These base totals were
used for making projections over the next ten years.

As shown in Block 2 of Figure 21, these three sources
of information were merged into one file of information.
In addition, Block 3 indicates that additional information
was generated within the program and also merged into the
original file. Finally the merged results were printed
and wrote on the basic DU tape. The variables that were
contained in the DU tape were DU(l), DU(2), DU(3), DU(4),
DU(9) and DU(lO).

Figure 22 presents the logical activities associated
with l) the selection of certain DU'S in order to process
only portions of a firm's total geographic sales area,

2) the further agglomeration of the basic DU's to a
reduced number of manageable DU's and 3) the projection
of the independent variables as the basis for preparing
the DU weighted indices of sales potential for each of
the years in the planning horizon.

Blocks 3 and 4 identify the activities associated
with the selection and agglomeration of the basic DU's.
Blocks 5 to 9 illustrate the activities of preparing the
annual DU data. Blocks 10 to 12 are associated with the
activities of preparing control totals for the run plus
looping through a maximum ten-year planning horizon.

The inputs into the run were the basic DU tape, the

selected independent variable growth rates and the selected

 

Farm)

 

INITIALIZE

 

 

GROWTH
RATES

DU 3'
TAPE

AGGLOH
DU'S

 

 

 

 

 

 

 

 

INDEPT
VAR'S
PROJECT

 

 

HEIGRTED
INDEX

 

 

PREPARE
PRINTED
RESULTS

 

 

 

 

TENJIEAR
CONTROL
TOTALS

 

12.

 

9O

Routine to prepare tenfiyear, agglomerated DU tape

Initialize run variables and array

Initialize the selected independent variables' growth rates

Read in desired first-level demand units from demand unit tape

Agglomerate selected DU's to reduced number of DU's

Process selected, agglomerated demand units

Make projections of independent variables per demand unit

Calculate the independent variables' combined weighted index
of sales potential

Prepare listing of agglomerated demand unit results for year
in process

Develop agglomerated, second-level demand unit tape
Loop through all second-level demand units

Prepare annual control totals on firm and environmental data

Loop through all ten years of planning horizon

Prepare tenqyear control totals

End of analysis

Figure 22.-—DU Selection, Agglomeration and Projection

91

basic DU'S to be processed in the operating system. The
outputs of the run were the printed listing and the merged,
selected DU tape. This was a FORTRAN program that affected
the same exogenous variables as in the DU Data Generator
plus variable NDUS.

Figure 23 identifies the logical activities asso-
ciated with the development of the order file that was

read into the D&E subsystem's operating system. AS was

 

discussed earlier, the decision had been made to use
blocks of customer orders. The basic purpose of this
program, called the Order File Generator, was to prepare
the stream of customer orders that were allocated to the
DU's and the DC's by the D&E subsystem of LREPS. One of
the basic problems associated with this stream of inputs
was to keep it to a feasible size. Even after the deci-
sion had been made to use blocks of orders, the amount
of time that was required to process these blocks in
either a sequential or random manner over a maximum of
ten years was still impractical. The run time from
initial tests using either tape or disk files was esti-
mated to be approximately four hours on the CDC 6500.
The size of the files that contained this information was
also seen to be quite large. For a ten-year cycle, it
was estimated that Six or seven full reels of order blocks
would not be unlikely.

Therefore, the decision was made to develOp "groups"

of order blocks. These groups would be composed of a

868:8 58 82¢.-.nu char.

sash—”ace no Fa

mason» menus as one» .38 see 4563 Ace:

one» soda nacho: co Ag nevus e923

oeusuecem es: 033 96..» seems 33

cussed mad—undead men? usage—6 Has 56.2» no:

eon» gas—6 ecu house.“ made—cog 96.5 £96.53 coca

eon»
sense—6 uou 8.003 canon—ea I96 moods havoc aoenee halt—ex

92

3.6.5 hopes p.38
3.83 .58 28.3 .5 S. 58.5 88

saved... .378 you .378 no hep-3. e5 #9695 nos

53.82«
.55 18a 3 £33.55 38.3 3.8.3 338236

$38.1 38.5 The...» a 58.5 93

«oath 13.8.: n to male 6.68s 323.8

execs .398 cussed omen—ohm

 

 

 

 

 

 

 

 

 

 

 

“~93
_MNgo

 

 

 

 

 

 

 

 

8.00.3 gecko eczema Snead
3&3 35326 .8- no.“ 8.83 assoc £963 903

093 nonsense use 9.003 nacho one due mug nose

and.“ ale-326 mob
cheese 9.3033 masons-u 3 some saloon-6 98 3033 PPS as

seam e305 .eeloaeao mone- dd- eeeoomm
one» a.“ 339:: pedunc- HHe 5.6.2.... 903

soda spoken—om sand
:93 eelounso new: .Hesuoe so come.— seeders eagles unanm

eeHC sewers 730s nus-326 .8?- snag

gases»: scene 5 enslave—6 cussed use ooh» belie—6 .8?-
med 38.33.. assoc no means: e5 9553er shoves» 33:35

cogs-.83 adv-«heavens?
nevus use gaseous oexoehu 5t. uoveuecem nacho ceased eaaasnuaca

:3 .so 5...: as. 823...» Sad-Son

mesons halve—6 no odd.“ ice“. 3. 3.38m

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

93

specific number of order blocks for each major customer
type. The exact number of blocks would be based upon
the amount of DC daily sales that a customer type would
most likely account for over the entire planning horizon.
A new group of order blocks was read for each DC in the
normal day's processing.

Figure 23 Shows how these order blocks and groups
of order blocks were developed. Blocks 1 to 3 of Figure
23 are related to the initialization of the variables
and arrays in the run. The basic input variables to the
run were 1) the "Sampled Invoice" tape including both
the line item and invoice summary detail, 2) tracked
product information that was used to not only select
the tracked products from all the products in the "Sampled
Invoice" tape but also to provide the basis from which
orders could be randomly generated and 3) the order group
blocking factors by major customer type including the
pseudo or randomly generated customer types.

Blocks 4 and 5 Show the splitting of the "Sampled
Invoice" tape into separate major customer type files.
Blocks 6 to 8 show the random selection of a specific
customer type's orders and summarizing these selected
orders into blocks of orders. Each customer type was
processed separately.

After the sampled invoices had been blocked into the
required number of blocks, the order blocks for the pseudo-

customer types were develOped. Blocks 9 to 13 used

94

individual tracked product detail composed of the model
product code, the inventory category to which this pro-
duct belonged, average sales volume information per
order, and the assumed probability distribution type

plus its parameters. The tracked product's inventory
category, whether it be based on traditional ABC analysis
or some other categorical basis, required data concerning f‘
the number of the tracked products in the category plus
the total number of products in the category of which it
was representative. The number of inventory categories
was also Specified.

After the tracked product information for a customer
order was generated, utilizing readily available, pseudo-
random variate generators for theoretical probability
distributions, the information for the tracked products
was generalized to the total product line for the customer
order. This generalized order was then added to the order
block for that pseudo-customer type. All pseudo order
blocks were generated for each pseudo-customer type
separately.

Blocks 14 to 19 represent the random selection of
the order blocks for each customer type and the merging
of these order blocks with those of the other customer
types to develop an order group. Block 19, which utilized
an assembly tape-write routine, shows that one full, 2400
foot reel of magnetic tape was prepared of order groups.

This order file was the input into the operating system's

95

D&E subsystem. The tape was read by the D&E until an
end-of-file occurred. The tape was then rewound and read
again. This rereading of the tape was assumed to be a
safe activity Since the probability that a DC would pro-
cess the same order group would be very, very slight.

Besides being written on the "Order File" tape,
the order file was listed on the printer. The output of
this program also included a tape file of the individual
actual and/or pseudo-customer orders that had been sum-
marized into order blocks. This tape file was later
analyzed by a Measurement subsystem supporting computer
program.

The operating system exogenous variables affected
by the Order File Generator were CSTBLK and all the
variables in the ORDGRP. The program was written in
FORTRAN except for the assembly, tape-write routine for

the order file.

CHAPTER III--FOOTNOTES

lBowersox, et al., Monograph.

2R. S. Underwood and Fred W. Sparks, Analytic
Geometry (Boston: Houghton Mifflin Company; Cambridge:
The Riverside Press, 1956), pp. 221-228.

 

 

96

CHAPTER IV

THE OPERATIONS SUBSYSTEM

Inputs, Outputs and Data Base Requirements

The OPERATIONS (OPS) subsystem was responsible for
the processing of the allocated customer orders at the
DU and DC stages and effecting whatever changes took
place within the DC and MCC stages of the physical dis-
tribution (PD) system as a result of the processing of
the customer orders. Stages 2 and 3 in Figure l of
Chapter I were the areas for which customer orders were
accounted. Stages 1 and 2 of the same figure were the
areas in which the PD activities of transportation, com-
munications, inventory control, unitization and facility
commitment were effected. The exception to the above was
the MCC stage which did not take into consideration
inventory control and facility commitment.

The OPS subsystem was, therefore, responsible for
processing the main physical distribution activities and
developing the outputs that would serve as the bases for
calculating the measures of sales, costs and service by

the MEAS subsystem.

97

 

The

98

main activities within the OPS subsystem were

conceptualized as happening on both a fixed- and variable-

time basis. The fixed-time activities were grouped

under four areas:

every

areas:

1)

2)

3)

4)

The

day

l)

The processing of the individual customer
order which included the allocation and
accounting of specific sales information
at the DU level plus the generation of

and accounting for customer service sta-
tistics at the DC level;

The processing of the order block's
summarized sales and product detail
information at the DC level;

The DC end-of-day activities in which the
DC'S inventory levels are checked with the
pertinent inventory management policy
variables to see if reorders for product
replenishment should be dispatched from
the DC to the supplying MCC's;

The DC end-of-day activities to see if any
shipments must be diSpatched to it from
the supplying MCC'S.

variable—time activities that did not happen

for the DC-MCC links were grouped under two

The arrival of a multiple-product reorder

at a MCC from a DC;

99

2) The arrival of a Shipment at a DC from
a supplying MCC to replenish inventoried
products.

The above are the major activity breakdowns asso-
ciated with the OPS subsystem. Because two of the
breakdowns happened at the end of day, fixed-time activ-
ities 3 and 4 from above were grouped into one major
end-of-day activity subprogram. Therefore, the OPERATING
SYSTEM is organized around five major computer subprograms.
These five subprograms were named INDORD for processing
the individual customer order at the DU and DC stages,
ORDSUM for processing the order block summary at the DC
level, DCEODAY for processing the DC and MCC end-of-day
activities, MCORAR for processing the arrival of an order
at the MCC level, and DCSHPAR for processing the arrival
of a shipment at the DC level.

Again, as in the D&E subsystem, a system flowchart
of the inputs, key endogenous variables and outputs, a
logical block diagram of activities, the programming
language(s) used, plus any peculiar programming techni-
ques and problems are presented and discussed for each
of the above activities.

The SUPPORTING DATA SYSTEM computer activities will
focus on the preparation of important DC-MCC product link
information. This was the only computer, supporting
activity associated with the OPS subsystem. AS in the
D&E subsystem, this program will be discussed within the

framework of the LREPS Supporting Data System flowcharts.

100

Operating System

 

The first component to be discussed is INDORD which
is the individual processing of the customer order.

Figure 24 presents the common data base variables asso-
ciated with the activities in this subprogram. Figure 25
presents the logical block diagram linking the component's
activities.

Activity Block 1 generated the order transmission
time (T1) from the DU to the DC to which it was assigned.
The activities for determining the length of time it took
an order to get to the DC were the generation of a constant
or average service time and then adding to this constant
an element of variability. For instance, a DU may have
been a constant 2 days plus a variable 0, l or 2 days from
the DC. This resulted in a range of T1 values from 2 to 4
days.

The constant service time was retrieved from data
base variable DU(S) and was initially determined in a M&C
routine associated with the preparation of DC-DU link
information. How the constant time is determined is dis-
cussed in Chapter VI on M&C activities. The retrieval of
the constant time was executed using EXTENDED FORTRAN
instructions for the CDC 6500 which allowed the Shifting
out of the time from the packed computer word.

The variable element, if it was desired, utilized
a Monte Carlo selection procedure that returned a value

of 0, l or 2. The routine was both a FORTRAN and assembly

lOl

ucaeeeooya yeoyo yesoaesoun.n~ eyswam

ecausoy mode-eooyd semen Hemyoc men 0» cysvem

soapyee
yeloueso uo mayo-eel unaueHsoHeo you seen cones-youcu euefismnoo<

8 eCAHIHHa you aside) Rye edeHov eeHee :Q eueOOHH<

on IydAIHHuC you i. + Na eoldu eoEee heave—5 eueaeoaeu

ecuusoy acumaeooyd no endanuasm

8 2:.i3..& you in“... a: 9:28 :1. 8 8H2

eoaeyee
yemoumso we asymmeee ucdaeasuaeo you seen :ouoelyoucd eveHsIsood

no ec«an~e«ayed you oh + «a nomad soweyee yemouesu eueasoaeu

eceoyea .709— eaws ace 3 Hence «ceases 257:5 uem

, neuyoueueo
hyouceena co semen «suds: uo aceoyem on ecdacueauyed eusmsuaeo

soda Heauyea ed on manna-es buyoqem u“ een ca guano

eco cu fleece assayed eduatfiasu was «en

0Q momma-es
mayoqee 0» no soy“ Aaevema» code-«mnneya yeuyo emu eueasofisu

on e on ue«u«oede e you yeoyo cs eeeooya o» ecaasom

Esme

 

 

. a:
>mMm
r5004

. L_ ___.-J

 

”.31...

68,:
NF

$59
3% + Nb

 

 

 

 

a <m
so
084 <

.3).
3mm

 

 

n..HL!.,hm> qummOOOLm FOE Hdflvtdg'eaN Can—“db

eyODsHsadboe “mo rev new
myouefiomseue ymo wed
eyOusFSESooe 9002 rep can
nyoaeanmsooe poo: wee
acoaayouoyu yepyo some. 9002
assauyoooyd » eeHee poo:
maqu you eoase a) cab
Suecaanaaa you eenee ‘95
luoax you meHem « Geo
quecwwu~a=u you sense a flea

aura: you yepyo we aceuyem
on onyanaasu you yeeyo no assayed

.0: one you sways». hyeyooleh

3:38
2:38
2:58
858
368.60
23880
338
Anyone
:38
8:8
€1.50

umam
unwed
couloo

 

sag
y.oos

 

W335, WDQQOBZN Mm;

dsoym no.6 x003 aevyo

evou .736on Home: 953

evoo .53ng Home: wraccdwem
yopeoauc« myoweuao >:« ecaa Heavyem
vase nee yea ucwdes m><

.nnc ucdy ofiau pyem unso

youeuau:« code on

eo«n we an enaeyuncoo huaoedeo
uuzosdynn ease madam one go acooyem
one you ocesdacn hafiev yeHHov Ken Nb
ncoduocs. eucewyee emau >yem
Haitians one + ego Uo

nyeesaon eoca.yd> end» ryea ammo
eeayomousu zyCVce>ca we .0: fleece
venueooyo mcflen xoo~n yeoyo «moo
penneooyd wcaen yepyo wnzo

yevyo you veuueaen vac: ucemoo
veaneoOyd «snob once on Heauceuom
venueuoyd wcden on coauswomncH

23 EHmomNmo

sesame
A n 5%
3 EE
SEE
BS
3 So
358
638
SB
.68
25a
8 Eco
leaded
oezy
58E
ES
MozzaH
8268
0263
mSazH

m5:

 

 

oszWuUQmm
655
8'8

 

 

102

routine that utilized data base variables DCP(7) and FARM.
DCP(7) contained the pointer to PARM, a common set of T1
variance parameters that could be utilized by several
DU-DC links. This activity block also used data base
variables IDUNOl and IDCNOl which are identified in
Figure 24.

Activity Block 2 initialized data base variable
RDCPC to one. This variable was used to allocate part
of a customer's order to a PDC if the majorly assigned
DC was an RDC-P. If the DC was a full-line DC, then
the entire order was allocated to the DC. The basis
for allocation is discussed below.

Block 3 tested to see if the majorly assigned DC
was a RDC-P. If it was an RDC-P, then Activity Blocks
4 to 8 were executed. If the DC was a RDC-F or PDC, then
the routine skipped to Activity Block 9. Both Blocks 2
and 3 were FORTRAN instructions that used data base
variables RDCPC, IDCNOl and DCP(8).

If the majorly assigned DC was an RDC-P, then
activity Blocks 4 to 8 identify the activities of
Splitting the order between the RDC-P and its assigned
PDC. The basis for the allocation was to accumulate
the weight for the RDC—P, inventory categories as a
percent of the total weight for all tracked products
and their respectively assigned inventory categories.

To accomplish the setting of this partial-line order

percentage, PLPC, a FORTRAN activity was developed.

103

The data base variables that were used were WTCU, PRCT(l)
which indicated whether an inventory category of tracked
products was an RDC-P's or a full-line DC's, PRCT(Z),
PRCT(3), ORDGRP(4) which identified the individual pro-
duct detail summarized for the orders in the order block,
IORD, IBLOCK, ITNPC and IDCTEMP which temporarily stored
the code of the PDC assignment for the RDC-P. IORD was
also the key to the calculation of the PLPC since the
percentage only had to be calculated for the first order
to be allocated from the order block. PLPC was then con-
stant for all orders in the order block. IDCTEMP was
specifically used to allow the use of a common set of
FORTRAN statements to update all variables associated
with both the RDC-P and PDC partial order shipments.

Activity Block 5 adjusted RDCPC to the percentage
of the order to be shipped from the PDC. This block
used a basic FORTRAN instruction.

Activity Block 6 calculated the order processing
and preparation time (T2) for the RDC-P plus the transit
time (T4) from the RDC-P to the selected DU. The calcu-
lation of T4 essentially followed the same procedure
used to generate T1. The data base variables utilized
for this task were IDUNOl, DU(S) which contained the
constant transit time for this link, DCP(7), PARM and
IDCNOl for the variable time element. The calculation
of T2 used a separate FORTRAN function subprogram that

basically followed these steps:

104

1) Using DCP(7), PARM and IDCNOl generate a
variable time element of 0, l or 2;
2) If the DC is within a certain percentage
of its capacity constraint, contained in
DCCAPC, add an additional day to each
order after this capacity limitation was
reached.
The T2 routine also used IDCNO, IDUNOl, DCP(8) and DCIS(8)
which indicated the size of the DC.

Activity Block 7 accumulated the information that
was needed by the MEAS subsystem to calculate the measures
of service for the DU and RDC-P link. The data base vari-
ables associated with this FORTRAN activity were IDCNO,
IBLOCK, DCIS(9), DCIS(lO), DCIS(ll), DCIS(lZ), PLPC,
ORDGRP(l), OCTDIS(l) which contained the necessary infor-
mation to determine the amount of sales dollars that were
delivered to the DC's customers within a certain number of
normal order cycle time (T1 + T2 + T4) days, and OCTDIS(2)
which was basically the same as OCTDIS(l) except that
customer orders was the basis for accumulation. The con-
cept of the total order cycle time (OCT) is discussed
later.

Activity Block 8 was a basic FORTRAN activity that
allocated sales information to the DU from the RDC-P. The
utilized data base variables were IDUNOl, IBLOCK, ORDGRP(l),
ORDGRP(Z), DU(l4), DU(16), and PLPC. The amount of the

order block allocated to the DU was one divided by the

105

number of customer orders, summarized in an order block,
times PLPC.

Blocks 9 to 11 were the activities needed to allo-
cate the sales information and generate the necessary
customer service times from the full-line DC to the DU.
If the majorly assigned DC was either a RDC-F or PDC,
then Blocks 4 to 8 would not have been used, RDCPC would
have been one and the full customer order would have been
allocated in Blocks 9 to 11.

Activity Block 9 calculated the customer service
times T2 and T4. T4 was calculated as described above
while T2 was essentially calculated the same as above
except that an additional test was made to see if a PDC
was being processed. If a PDC was being processed, then
it was assumed in the modelling of the activities of a
PDC that the amount of goods being shipped from the PDC
warranted the possibility of pooled or consolidated
shipments to the individual DU's. Therefore, a procedure
was developed for the scheduled shipment dispatch of a
percentage of the customer orders on a pooled basis. If
the dollar amount of a customer order was less than a
certain amount (SDSM), then a random number, generated
from RANF, was used as the basis for determining whether
it was one of a specified percentage (CSDP) of the orders
that received daily shipment dispatch. The remaining
orders less than SDSM plus all orders greater than SDSM

went on an approximated, dispatch schedule of Mondays and

106

Thursdays of simulated time. Besides the above variables,
these FORTRAN and assembly routines used IDUNOl, IDCNO,
DU(S), DCP(8), PARM, DCP(7), DCCAPC, DCIS(8) and IDCTEMP.

Activity Block 10 allocated the sales information
to the DU from the full-line DC. This activity used basic
FORTRAN instructions plus data base variables RDCPC,
IDUNOl, IBLOCK, ORDGRP(l),ORDGRP(2), DU(13) and DU(lS).

Activity Block ll accumulated the information to
calculate the measures of service for the DU and full—
line DC links. The activity was FORTRAN based and used
data base variables RDCPC, IDCTEMP, IDCNO, IBLOCK,
ORDGRP(l), OCTDIS(1), OCTDIS(2), DCIS(9), DCIS(lO),
DCIS(ll) and DCIS(lZ).

Figure 26 shows the important variables associated
with the OPS subsystem routine ORDSUM. This routine's
purpose was to process the order block's summarized sales
information and product detail at the DC level. Figure
27 shows the block diagram of activities for this routine.

Block 1 was a check to see if the majorly assigned
DC was a RDC-P. If it was an RDC-P, then the order block
summary had to be allocated between the RDC-P and the PDC.
If_it was a RDC-F or only a PDC, then the entire order
block was accounted for at only one DC via Activity
Blocks 7 to 11. The data base variables utilized were
IDCNOl and DCP(8).

Activity Block 2 accounted for the portion of the

order block's sales information that was allocated to

107

undo-eeehm hue-lam xeeam uevLOI|.e~ eauuau
nadvseu undo-eeeun condo Helge: add ea nude-z

8 .573,“ .8» 82258 D3525 a 53.2.. 93

x83 .38.. lb 32.. 3d: .3333 B :2 .3388 828a
neuueueuee hueu=e>cd on endanfiasu aceeeum

hueweuee
anode! aoetoe .5 «32. iii? Excedu hear—e euca§o<

H:OH 8 adHlHHa 0. lav-8 C..~ .0IH§0<

Hosea on ocan-mnnu an ceauqluouca sea-o cacao-5004
ocaaseu made-eoeun uo ecaauaapm
Luca: you neaueweuao nuoanebca dad anseuna neon

x83 .326 lb
scans cede. .eaeseoun nH unenlceteeuueacebnd .uooaneun convex

eedueueuqu hheacebnd u.muunx n-eoeum

huowoado
exude: aoeuheo :« «swan: unclean. n.xee~n geese eu-Haisoo<

mice: .3» p.373 3335604

He}: 8 endfiuadzhen we sedan-Load .07. 3.1.5604

:5 13.53 3 8 3.3... 33?- h 8. 3 x26

Hepea on a a. mud-l5» xeeab unvue unooeun ea oeuuaem

. 285V
~

 

5400mm
890x.»

 

 

 

 

 

 

 

 

 

 

J

a mu: <m
Samoan
mEoOxm

 

0
UN

 

 

 

 

 

 

PE
n33.
. :63
N .
a.
\z #1\/
d .02 (v
. «C 2 /, \
E85

newnedu¢> mcamnooehm hhdnndm neobolc.o~ euuuau

use: no muouzevca

unseen unwae: acenndno no
mean» Leone aha

nefidn on: 0.5

ueHen oneo aha

neat. 0230 OLD

mead» unwae: Gab

neadu udaaov aka

muuax .3.“ .320 he accouem
8 .5738 Lou ueouo he «coupon

.0: 8m he.“ em-Louu Egon-e...

38%
ESS
2328
8328
3:28
8:28
Anhvmmoo
3:28
$8.50

9.3m
DARE
col-bu

 

ng
H103

 

§§§> maggfi Ex

eooo uoavonn Hope... ”:33

evoo 9260.3 floods 935:QO
heueeaocfi Dewey-o t2 eczuaeauudm
neauomeuee reflect; go .0: .389
310.3 use?) 8

£3.51:- Sm 37.. 093 um

x003 50C each.“ Levi—O

32390.3 @599 x003 .520 3.6
penneeoun ”Eden even on H-Sceuom
“33000.3 9505 on 5333...;

20m EHmUaQ

An :9;
AN :2:
A A from“.
828
9.8

3 I8
5.85
68mm
62x:

95%:

m3

 

 

23m 695
a BO 093
mmuam

 

 

 

108

the DC based on the partial-line percent, PLPC, calcu-
lated in INDORD. This FORTRAN activity used data base
variables IDCNO, IBLOCK, ORDGRP(l), ORDGRP(Z), ORDGRP(B),
PLPC mentioned above plus DCIS(16) through DCIS(ZO).

Activity Block 3 accumulated the number of orders
that were processed from the order block at the RDC-P.
The assumption had been made that two orders would be
accumulated for each customer's order received at the
RDC-P. Therefore, one order was accumulated at the
RDC-P plus one was accumulated at the RDC-P's associated
PDC. Also the assumption had been made that only one
PDC would serve the same DU as a RDC-P. The data base
variables associated with this activity, which was pro-
grammed in FORTRAN, were IDCNO and DCIS(21).

Block 4 accumulated the order block's shipment
weight, which was allocated to the DU's, in the correct
customer weight category. The correct weight category
was determined by taking the ratio of one over the num-
ber of customer orders in the order block multiplied by
the total weight in the order block, ORDGRP(Z), times
PLPC. The total weight in the order block, ORDGRP(Z),
was then added to the selected category. The other data
base variables utilized in this FORTRAN activity were
IDCNO, IBLOCK, DCWB and WTACUM.

The next two activity blocks subtracted the order
block's summarized product sales detail from the RDC-P's

inventories—on-hand for all tracked products and their

II.

109

respective inventory categories. These activities were
programmed in FORTRAN and used data base variables IDCNO,
IBLOCK, PRCT(l), PRCT(Z), PRCT(3), ITNPC, PRDC(4),
ORDGRP(4) and PLPC. PRCT(l) allowed the activity to
distinguish between RDC-P and PDC inventory categories.

Activity Blocks 7 to 11 basically followed the
same procedure as Blocks 2 to 6. Block 7 accumulated the
order block's sales information at the full-line DC.

This activity used data base variables IDCNO, IBLOCK,
ORDGRP(l), ORDGRP(Z), ORDGRP(B), IDCTEMP, DCIS(16) through
DCIS(ZO) and RDCPC, the full-line DC percent of the order
block's sales information. Block 7 was also a FORTRAN
activity.

Block 8 accumulated the number of orders for the
order block at the DC level. It was programmed in FORTRAN
and used variables IDCNO, IDCTEMP and DCIS(Zl).

Block 9 accumulated the order block's shipment
weight in the correct customer weight category as was
done for the RDC-P in Block 4. The FORTRAN activity used
variables IDCNO, IDCTEMP, DCWB, RDCPC, and WTACUM.

Activity Blocks 10 and 11 again adjusted the full-
line DC's inventories-on-hand, PRDC(4). These inventories
were reduced by the sales, ORDGRP(4), in the order block.
The other data variables involved in this FORTRAN activity
were IDCNO, IDCTEMP, PRCT(l), PRCT(Z), PRCT (3)_.ITNPC,

IBLOCK.

110

Block 12 signifies a return to the D&E normal sales
processing routine that was linked to this OPS routine.

After a DC's simulated sales quota and the individual
customer types' quotas had been reached, then certain
activities were assumed to be performed at the end of day.
These activities primarily centered around the review of
the inventory levels and the shipment of product replenish-
ments from the MCC's to the DC being processed.

Figure 29 shows the block diagram of activities
associated with the DC end-of-day processing. Figure 28
lists the data base variables that were manipulated and
used within this major subprogram. These variables, as
was done with the prior OPS subsystem routines are only
listed in the text while a brief description of the vari-
ables can be_gained by referring to Figure 28. A more
detailed description can be gained by referring to
Appendix 1.

Activity Blocks 1 to 12 in Figure 29 were designed
to accumulate certain inventory information plus also
determine if any product reorders were to be dispatched
from the DC. Block 1 allowed this routine to process
only the inventory categories for which this DC was
responsible. This was especially critical for RDC-P's.
Block 1 was programmed in FORTRAN and used data base
variable PRCT(l).

Activity Block 2 performed the updating of certain

inventory status variables based on two conditions.

111

32:33 pals-1: glam E:
3.3!: 35:002.“. Inad- bnulv HIE min 3 E..—
‘Iutook I." 8 ha 58: :4 g 3

In: no 503 e: in Sol-sou

Elegaflasliasag

1: RTUQ. :5 .IM Ian—g 9'3 3 .IE 33‘:

8 3 €1.2- anal-S

Boos—5.313.. $331.56
531:: in. 8:8: :1:
_Eébuoliaoaufiliazflil:

.3155:
iiia.§a.-Inl.§l3llflnn

ixaflsiiullii.=§
I: 098235 in 3:545... 3'9!-
vioi '33 Bin 50531-41; algae-Id

B:53-.§a§§

.IS 2 v. . r. .3- 535-0....
:1- ..5! .502.- ..843-5! [in Si: 8.18 .3139

and»! Sign: i

Iii-.3253;

glflggagg

31.33.5509
Iniggnga§k§.nua-n

«mg—vial; .8! «262..
E33 I“ on: In:

gig-nth I3
.4 5 ma '- 3 a; .55.»!— E% In... Plus-o 3

3:38.. hi... ill-Anu-

 

ni: gun-2v align 3:00: .3

.1385. 5E 8.18 a- »! a. .3 alibi»! 330.1 5

.3555 El! «1 Aug so:
.033 EBB—.4 Add L: 0:38.. iv

goofinauEQ-EE

Iagifiloflfi
ggflgifliiéan-nn‘n

.mfivEHXI-EL I! €62;

Ian-ouch. 930A 31 i

.IE. slag-p5 he I: 3 .H .13.. Iv.»- ib—

uki Ell-«SE 1 35.58 a -

influx. and... i - 3E3! I5 1—

Fuou-u In P31 «chino Fan-Ea lull»).

ESE-{£1114 A1533:

End-lg

D352: 7.59 id :3 135—Moving 3 a9. 1‘. .0. an
on!!! 12.35

:5 .3 Dali-:5 : 33:3 323.. u 3 o.- 3 33.6

Din-00! ad 30v al.1009- In:
323...» lififili I: 25.8.: 3.535.!» :33
:33...» .35- 72: E 8.1:

tuna-Inn:
:Sgiiinuoaluflflgcfihi-E

.3Un33 git: :4 3.3.:

Anton EDI:
38 €350.13 :- !nnoeil In 315.33 37.7.1.

 

MEI-$23K .a 38 X Eadie-EH .a

.3. 8 5333.5 n BE. .5 Saint .n
. .~

:2. En): N «6 v.3»-
155 c .5... J ”Eat: c 1:. l
.312... .EE 58.. :3523 only .359
1. 3o 8.5 3.01.. .933!” PS Click
Bein- g... 8.18 Sofia
1 38 3.693 352.» 1.8... “38.5,:
:8 £563.03 "Bangui.— 2695.:
533» 3.3335. Ea A885:
33%.: ac: 911.158 . 8.. ”38.:
u it I. E 33.3- .Efltm 3.3%
:3 veg-“3:759 RUB:
.3325 a... o 8: a. 55 J: 58.8
on: a. v o! Eng... 33...?- ua .o: Rico—Go
158 .323.— it 8: .239: A3859
.Ifi no: 35... 1%.. I63 ES
.36.... 3131.. a. .2 1.5. 38.3
95th

.3505 .i

nan: Miami!

has“ new vain-ao- 8: 369:

39:3; .3» IS to. N.— 8: A58:

:1. auzuh 1.3.. «a as: 1.8.. :33:
8.3“!“ 8: 23:53.5 o 3: SOB-L
1:: so Fun-F: M38!—

AETm Eel-2.2.2 Sun!

to: . 33. A38!

E31 .5 a: 5!: it... IE 3.5....
:3 9:3 D352: .3 85. 3:3,.

.13 «2.8.1 1.8- 835 AGE!

.8 a 8.1 73- 52.5; ASHE

53 «I: Duns-u .5 5-135.. "SUE
totem-9.0 Envy—J us .2 30.— “KI-fl
3832a 8.35» IS Pin .5.

.. IE... 8.. + x5 8 :39

.5»: i o z. 8.18 5E8

389.1 :3! Byron 3.23

§

112

Condition 1 was the normal updating of a time-integrated,
inventory-on-hand variable, PRDC(3), which at the end of
the quarter of simulated time could be divided by the
number of workdays in a simulated quarter of the year to
get the DC product's average inventory level. Condition

2 was one in which the inventory for a product had stocked
out. Two variables were updated for this condition. A
time-integrated, stocked-out cases variable, PRCTDC(3),
was updated with the number of cases that were presently
stocked out. This variable was used by the MEAS subsystem
to determine a customer service penalty time for inventory
stockouts that was added to the normal order cycle time to
obtain an average total order cycle time. The other vari-
able, PRDC(5), was updated every day in which a product
was stocked out in order to be able to calculate the
average and standard deviation of the product stockout
delays given a stockout had occurred. This routine was
programmed in FORTRAN and also used data base variables
IDCNO and PRDCM) .

Blocks 3 and 4 were used to make an adjustment to
the time-integrated inventory-on-hand, PRDC(3), for any
outstanding DC product reorders. If there were any out-
standing DC product reorders, indicated in variable
PRDC(6), then the reorder quantity (ROG), in variable
PRDC(6), was added to PRDC(3) in order to be able to
approximate the total average inventory committed to this

DC for this product. If there were no outstanding ROQ's,

113

then the next tracked product was processed. These
FORTRAN activities also used data base variable IDCNO.

Block S was used to process all the tracked products
in an inventory category. Processing the tracked products
by category was necessary because certain data base,
inventory variables were only accumulated and processed
on a categorical basis rather than a product basis. This
block used data base variables PRCT(Z) and PRCT(3).

After the inventory status information had been
accumulated for the DC, the routine then made a check of
all the products in a category for any product reorders.
In designing the mathematical model, three basic inven-
tory management policies had been designed. Block 6
checked for the first type of policy which was a daily
reorder point system. Data base variable PRCT(S) con-
tained the inventory category's policy indicator. It had
been assumed that all the products in a category used the
same type of policy since there was the possibility of
sample products being used to develop inventory category
information.

Block 7 checked to see if the inventory category
was an optional replenishment type policy based on a
periodic review. Block 8 checked for the time for
reviewing inventory levels given that the inventory
policy was a hybrid or a combination daily reorder point
and optional replenishment inventory policy. These were

the basic policies built into the model to allow the

114

flexibility of using various types of policies. Blocks
5 to 8 were programmed in FORTRAN and, besides using
data base variable PRCT(S), PRCT(G) was used.

Given that the products in a category used a daily
reorder point or hybrid system, Block 9 checked the pro-
duct for a possible reorder. The product's inventory-on-
hand (IOH), in variable PRDC(4), was checked against its
reorder point, ROPl of PRDC(l). If no reorder was neces-
sary, then the next tracked product for the category was
processed. If a product reorder was necessary, then
activity Block 10 set up the reorder. Block 9 used FORTRAN
instructions plus data base variable IDCNO.

Activity Block 10 used a FORTRAN subprogram to set
up the product reorder. This subprogram set data base
variable PRDC(6) by subtracting the IOH, in variable
PRDC(4), from PRDC(Z) which was set by an inventory
management routine in M&C. PRCTDC(2) was adjusted for
another single-product reorder plus PRCTDC(4) and
TPDEM(l) were adjusted for the reordered quantity to
approximate the case sales for this product. In addition,
MCORAR event attributes 4 and 6 were set for the possible
multiple-product reorder. This last activity used data
base variables PRDC(6) plus WTCU. Also data base vari-
able IDCNO was used in all of the activities in Block 10.

Block 11 was used to process all the tracked pro-
ducts in an inventory category. It was a FORTRAN activity
that used data base variables PRCT(Z) and PRCT(3). Block

12 was used to process all inventory categories ITNPC.

115

After all inventory categories had been processed,
Block 13 checked the MCORAR attribute 4 to see if any
single-product reorders had been necessary. If so, then
a reorder had to be dispatched via Block 18 and 19. If
not, then the routine to test for MCC-DC shipment dispatches
was processed in Blocks 20 to 28.

Activity Blocks 14 to 17 were used to set up any
product reorders using the basic, optional replenishment
system. Block 14 checked to see if it was time to review
the inventory levels. If it was not time, then the next
inventory category was processed. PRCT(6) was used to
check this time of inventory review.

If it was time to review inventory levels, then
activity Block 15 checked the IOH in variable PRDC(4)
against ROPZ in variable PRDC(l). EXTENDED FORTRAN
instructions were necessary to shift out the ROP2 from
PRDC(l) for checking purposes. If a reorder was not
necessary, then the next tracked product was checked for
this category. If a product reorder was necessary, then
Block 16 followed essentially the same procedure as des-
cribed for Block 10. All the same data base variables
were adjusted as in Block 10. Block 17 was the basis
for processing all tracked products in an inventory cate-
gory. Block 17 used data base variables PRCT(Z) and
PRCT(3).

Given that single-product reorders had been developed

in the prior activities, multiple-product reorders were

116

dispatched to the supplying MCC's for the DC being pro-

cessed (IDCNO). In order to accomplish this multiple-

product reorder diSpatch, a FORTRAN subprogram was

developed that followed these basic steps:

1)

2)

3)

4)

5)

Add the tracked products' weight to REG(4)
and then extrapolate the tracked product
weight for the firm's total product line--
used data base variable REG(15) for extra-
polating MCORAR attribute 6;

Assign the products to their supplying
MCC's using data base variables DCP1(l)
and IDCNOl plus MCORAR attribute 4;

Split the total weight of the reorder
between the MCC's based on the MCC-DC
weight split proportions in variable
DCPl(2);

Generate the reorder lead time elements
T1, the reorder lead time of transmission,
using data base variables DCP1(3), PARM
and IDCNOl, plus the MCC order processing
and preparation time, T2, using data base
variables MCC(l), and PARM--do this for
each of the DC's supplying MCC's;

Dispatch a multiple-product reorder event
to each of the supplying MCC's that has a

weight proportion greater than zero plus

117

adjust DCMCC(2) for the generated reorder
lead time elements.

In generating the reorder lead time elements T1 and
T2, the same basic routine that was used in generating
customer service time elements T1 and T4 was used. The
only differences were that the Monte Carlo procedure
returned, for instance, a 4, 6 or 8 instead of a 0, l or
2 plus this variable element was not added to any type
of constant service time.

Block l9 completed the reorder dispatch subprogram
by indicating that a multiple-product reorder was dis-
patched for each supplying MCC--used data base variable
NMCCS. The overall routine was programmed in FORTRAN,
but it used some of the special features of EXTENDED
FORTRAN available on the CDC 6500.

Blocks 20 to 28 accomplished the investigation of
the outstanding MCC reorders for the DC being processed
(IDCNO) to see if any shipments should be dispatched to
the DC. The procedure was to determine if there were
any reorders at the MCC that could be dispatched. Block
20 checked this using data base variable DCMCC(4). If
there were no outstanding reorders, then the processing
went on to the next supplying MCC for this DC--indicated
by Block 28 which used variable NMCCS.

If reorders were outstanding, a check was made to
see if there was enough weight accumulated, DCMCC(S),

greater than the minimum shipment weight for either a

118

truckload or carload, MCCWB, to dispatch a shipment.
This checking was done in Block 21.

If the shipment weight was not large enough to
initiate a minimum shipment dispatch, then the day of

simulated time was tested to see if a scheduled shipment

 

dispatch should be made. A shipment was diSpatched if
none had been made over the last "shipment dispatch"
review period. The scheduled shipment was necessary to
ensure that at least one shipment was made within a
minimum number of days. This FORTRAN routine used data
base variable MCC(2).

If this was the scheduled shipment dispatch day,
Block 23 made sure there was weight to be shipped. This
block used data base variable DCMCC(S).

Activity Blocks 24 and 25 initiated the MCC-DC
shipment dispatch. Block 24 calculated the transit time
for the MCC-DC link. This generation used the same basic
procedure used for generating reorder lead time element
Tl plus data base variables DCPl(3), PARM, and T4.

Activity Block 25 was the FORTRAN routine that dis-
patched the shipment from the MCC to the DC. In develop-
ing the MCC shipment dispatch, DCSHPAR event attributes
1 through 4 were set using the calculated T4, from the
last Activity Block,plus IDCNO and DCMCC(3). In addition,
the total number of multiple-product reorders, DCMCC(l),

was adjusted with DCMCC(4).

119

Activity Block 26 updated the reorder lead time
accumulator, DCMCC(2), using data base variables IDCNO,
the calculated T4, and DCMCC(4). For each multiple-
product reorder that was outstanding, T4 was added to
DCMCC(2). DCMCC(4) was then reset to zero in this
FORTRAN activity.

Activity Block 27 accumulated the dispatched ship-
ment weight in the apprOpriate weight Category of the
alternative weight categories, DCMCCl. This basic
FORTRAN activity used data base variables IDCNO, IDCNOl,
DCMCC(S), the dispatched weight, DCP(8), the DC type
which enabled the routine to determine which of the
weight categories, MCCWB, was used for a certain type
of DC.

Block 28 shows that all the supplying MCC's were
checked to see if any shipment diSpatches were to be
made. After all the MCC's had been checked, Block 29
indicates a return to the D&E normal sales processing
routine that called this OPS subprogram after all cus-
tomer sales had been processed for the simulated day of
operation.

The next major component in the OPS subsystem is
the processing of a MCC order arrival. This is a vari-
able-time event activity that used the data base vari-
ables listed in Figure 30. The logical flow of activities
are presented in Figure 31. Activity Blocks 1 and 2 of

Figure 31 show the EXTENDED FORTRAN activity of setting

120

madnoooorm Hapauu< acute conun.an ousmaa

sm>thumxm: mm<d ow :hduom

house-u so unmao: acosnwna Hauov on» cucua:

sada owns you uauaoou unavouanoanwvasi wsaucdauvsb one: one cud

houuoou :« uaosuoun Han nwsouzv “cog

xcaa nag» you ascends. sue: on «caucus cu<

houuoon :o wasnoua uncooum

Havana: hound out op on a uncooua cu osausou :ofiaunoanddud>=

noapsauu> wcfiumoooum Hirduhd nacho uu:nu.on oustm

.E

 

 

 

 

 

 

 

 

 

 

 

noudoauca mam + out an “echo so a: Anvooxua
QEOHM3 out an v.9...~ nuovnoou vounuuasa no .02 Aavuoxuo
ma¢am= uopuoou so nuosvoua vo>wooou 00x acououm Anvoozua
.3 mpbmebo
Hl ,
mmmomomm
ma<am=
.m
bl
comm
me<nm=
.H nauseous noxosuu do .0: fiance mazeH
p: acoaaagu Hanna .0
a 38 8: .n

uovaoou so avonuoum .3
0000 on souv2H0nocH .n
ovoo unobm .N
Hd>uuhd Mo aids .H
.novsnduuvd ace». m<zoox
webmzH

ZOHBQHmomma mz<z

 

 

 

 

A<>Hmm<
«memo
QUE

 

 

 

 

121

the indicators showing the products that were added to
the total list of products that were awaiting dispatch
to the DC. These Blocks used data base variables
DCMCC(3) and ITNSP plus MCORAR event attributes 3, 4
and 5.

Activity Block 3 updated the total number of multiple-
product reorders that had been received for the DC-MCC
link being processed. This basic FORTRAN activity used
data base variables DCMCC(4) plus MCORAR event attributes
3 and 5.

Activity Block 4 updated the total weight to be
dispatched on the next MCC-DC shipment. This FORTRAN
activity used data base variable DCMCC(S) plus MCORAR
event attributes 3, 5 and 6. After updating the total
weight to be shipped, Block 5 indicates a return to the
GASP "EXECUTIVE" routine to process the next event in
the queue.

The last major component of the OPS subsystem is
again a variable-time event activity used to process
the arrival of a shipment to replenish product inventories
at a DC. This activity, called DCSHPAR, uses the vari-
ables listed in Figure 32 to update the inventory status
variables. Figure 33 shows the logical activities to
accomplish this updating of the status variables.

Activity Block 1 checked the products on the ship-
ment, specified in DCSHPAR event attribute 3, to see if

their present, DC inventories-on-hand were stocked out.

122

mfianoofia 1.2.: 225.3 8.39 23E

sm>thownw: mm<o 0v :hnvom

H¢>auu¢ acolnwnn :« uposcoun Ha: nusousg aooq

abucouucu
can vouch .undnwsouhuou:o>:a o» huausosv hovuoou u.vo=voua uu<

huuacdav nouuoou uncooum

nousuaoa usoxooau hhovsobsd oudon: .0» MH

obavamoc ad unenccouhhounobna an com

tobacco» avoathn Han uncooum

H.592 9513. on o» 8: . 3.8.3 3 838.. .ofl»-.335>..

83.2; 9.2825 15.5 ago-fig...” 83.3.9»:

.sufiiso. 3% $8.03. .3 3m $338

. assuage“... 3% 08x8». 95 SCmHoa
: nouvvhoxoon suds: undo vsoouim Annvaoo
nasaxooun scum no .0: ago Afivonsomm

 

 

 

 

 

 

 

 

:8 .8233: 08 33.338 + as. Scones
09 can uosuoun hon unit vsoxooan account Anyonmm
and: so mucusn>=H Aavonxm
. whamhbo
A<>Hmm<
pzmmemm
on

 

 

 

 

 

 

 

82.3!“ 08 min—33.6 + 08 $59:
as... so €3ch 369E
3262a v8.3.3 do .2 1.8... each
ouoo on souvsHOnch .3
uaunoou so uaosvoum .m
88 and .N
thauhd «0 ends .u
33.5.5». as». 5568
. mszH

 

 

 

onamHmummo @242

123

If a product was stocked out, then certain stockout
measures, PRCTDC(1), DCIS(13), DCIS(14), DCIS(IS),
were updated in Block 2. These FORTRAN activities
also used data base variables PRDC(4) and PRDC(S) plus
DCSHPAR event attribute 4.

Activity Blocks 3 and 4 updated the inventories-
on-hand for all products in the received shipment. The
indicator of an outstanding product reorder was also
set off. These activities used data base variables
PRDC(4) and PRDC(6) plus DCSHPAR event attributes 3 and
4. After updating all product inventories, the routine
returned to the GASP "EXECUTIVE" to process the next

imminent event.

Supportinngata System

 

The only computer supporting activity for the OPS
subsystem was used to establish some basic DC-MCC product
link information and punch the information in a form that
could be read exogenously into the Operating system.
Figure 34 outlines the activities that were used in this
EXTENDED FORTRAN activity that Specifically developed the
exogenous data base variables DCPl(l) and DCPl(2). DCPl(l)
contained the packed computer words that indicated the
products that were to be supplied over the alternative
MCC-DC links. DCPl(2) contained the proportions of the
total replenishment weight to be shipped to the DC from

each of its supplying MCC's. These proportions were

 

 

PRODUCT

 

 

 

 

 

 

 

 

 

 

 

 

 

 

MCC
DNTA

 

 

 

 

 

 

 

 

 

 

124

Set up DC-HCC product link and replenishment weight proportions

Sum total weight for all tracked products

Process each MCC ranking scheme
Check each tracked product
Process each in-solution MCC

Check to see 11' this ranked 14cc has product
Set product indicator and add weight proportion for MCC selected
Loop through all MCC's

Loop through all tracked products

Check each potential DC to see if it uses present scheme

' See if DC uses present ranking scheme

Assign data to DC

Loop through all potential DC's

Reset product indicators and MCC weight preportion accumulators

Loop through all MCC ranking schemes

Prepare DC-MCC output results

End of analysis

.Figur. 3h.-DC2HCC Link Information Generation

125

extremely critical when sampled, tracked products were

used instead of the total product line for inventory

control purposes.

The input information into the program was:

1)

2)

3)

4)

A control card that contained the number
of potential DC locations, the number of
supplying MCC's, the number of tracked
products, and the number of priority
ranking schemes for the potential DC's;
One card each for the alternative ranking
schemes that indicated the priority with
which DC's desired to be supplied from
the alternative MCC's;

Tracked product information, with one
card per product, that contained product
identification information, total domestic
weight sales in a prior year, plus an
indicator for each MCC as to whether the
MCC produced the product or not;

One card for each potential DC that indi-

cated the ranking scheme it was to use.

The details of the program are explained in Figure

34. Block 1 developed the weight proportions for all

tracked products. Blocks 2 to 4 accumulated the weight

proportions and set the product indicators for each of

the MCC's of highest rank in the present priority scheme

and for all tracked products.

126

After all tracked products were processed, the
potential DC's were checked to see if they used the pre-
sent priority ranking scheme. If they used it, then the
packed, product indicator words plus the weight propor-
tions were assigned to those DC's. Blocks 9 and 10
indicate the resetting of the product indicator words
and weight prOportion accumulators plus the processing
of all priority ranking schemes. Finally in Block 11

the results were punched for all potential DC's.

CHAPTER V

THE MEASUREMENT SUBSYSTEM

Inputs, Outputs and Data Base Reguirements

 

The MEASUREMENT (MEAS) subsystem had the task of
developing the criteria for evaluating alternative dis-
tribution plans that had been simulated. The criteria
of evaluation were developed over the planning horizon
and focused on measures of costs, sales and service.
The DC cost measures were based on the five primary
physical distribution activities of tranSportation,
materials handling or unitization, communications,
facility commitment and inventory control. No costs
were accumulated at the DU or MCC stages. The measures
of service focused on customer service plus the service
aspects concerning the shipment of inventories between
the DC and MCC stages of the physical distribution system.
Sales measures centered on the amount of sales that had
been accumulated for each DU, in-solution DC and MCC-DC
link.

In line with the above statements, the OPERATING
SYSTEM of the MEAS subsystem incorporated eight major

computer subprograms:

127

l)

2)

3)

4)

5)

6)

7)

8)

128

SERV--the routine to calculate the measures
of customer and DC-MCC reorder service;
EXTRAP--the routine which extrapolated the
traCked products' average inventory charac-
teristics for the firm's total product line;
OBTCST--the routine to calculate the out-
bound transportation cost from the in-solution
DC's to their assigned DU's;

IBTCST--the routine to calculate the inbound
transportation cost from the supplying MCC's
to each of the in—solution DC's;

TPCST--the routine to calculate the cost of
preparing customer orders for DC shipment
dispatch;

COMCST--the routine to calculate the cost of
DU to DC order transmission activities, for
which the DC was responsible, plus the activ-
ities of processing the order up until the
time that the order was physically picked
and prepared for shipment dispatch;
FACST--the allocated, investment cost for
land, building and equipment at the in-
solution DC site;

INVCST--the cost of holding or carrying
inventories at the DC stage, the carrying
cost for pipeline inventories for the MCC

and DC links plus, possibly, the cost of

129

handling and preparing the MCC dispatched
shipments to each in-solution DC.

These measures of cost and service were calculated
quarterly using the base data developed in the OPS sub-
system. The measures were inputted to the MONITOR and
CONTROL subsystem which used part of the variables for
dynamic feedback responses and which outputted all the
measures to the REPORT GENERATOR system. The measures
of sales were left intact, as received from the OPS sub-
system, and merely passed them along with the measures
of cost and service to M&C.

In LREPS the assumption had been made to output
model information on a quarterly basis. Therefore, the
MEAS activities were only utilized at the end of every
quarter of simulated time. The rationale for the quar-
terly outputting of information was similar to the
rationale for developing end-of-period accounting reports
that not only show historical information, such as a
profit and loss statement, but also snapshot, status
information such as the information shown in a balance
sheet.

All of the activities in the MEAS OPERATING SYSTEM
used basic FORTRAN instructions. Therefore, no partic-
ular mention will be made of the utilized programming
language(s) in the detail description of each of the
above routines. However, a system flowchart of the

variables used in the routine, the logical block diagram

130

plus any programming problems or peculiar programming
techniques will still be included in the detailed routine
discussion.

The SUPPORTING DATA SYSTEM for the MEAS subsystem
had three computer activities. The first routine gener-
ated a matrix of calculated highway distances from each
of the potential DC locations to a sample set of desti-
nation points for each DC. This matrix of highway dis-
tances from the potential DC's served as part of the
inputs into the second supporting, computer activity of
generating regression equations. The regression equation
coefficients were the basis for determining the outbound
transportation rates from the in-solution DC's to each of
their respectively assigned DU's. The other inputs into
this second computer activity were actual, weighted
average freight rates. These average rates were based
upon the percentages of total weight that were shipped
in the selected order weight classes. The third sup-

porting computer activity generated these percentages.

Operating System
The first major component of the MEAS subsystem is
the routine to calculate the measures of service (SERV).
Figure 35 lists the variables associated with this
routine, while Figure 36 identifies the sequence of activ-
ities with which these service measures were developed

for each in-solution DC.

eeusuee: eoabhem eveaooaeoln.mn euswam

cadence ueuue:unuonu:e 0%: o» suspem

:uu-—““u_“_'v

eoaumaueaoemdco hhouce>ca on eueHoaeuer on ecfivsou o» xcaq
meHDofiue> .nehsnee: eow>hem uo coaaeasuaeuut.nn emdmam

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

aq<
ouxnoo
xcaa oozuoa nose sou ease need emeuebe eueasodeu .o ug<u 900 Have» wbe canoesoo amdzoo
_ 9332s men“: .502 338E
.e.m.< acosauoaota pesto coo: vamsoeoo
zoo esoavhonoua ueHHou «ease 9002 AHVmHopoo
e e he soon w>e _
end» cowbuee eweae>e causesoo eueasoaeo .mw uq<u may oMeMeo ”soxoovn >wwzwwm mewwuwm
_ sqaou ssoxoo». m>< Assvaoa \\\)/J,
m.momm oeueouoxoen noose aceouem Anavaoc
802 so Hdvov m>< abvaUQ
ecowuHOQoua end» eHohu Leone Heshoc eueasoaeu QA<U smo hep ppm ANHVmHOQ
.a _ amo m>< AsscmHoa
moHem poo Hanna: sun can Aosvmsoa
wano poo Hanna: m>< Amcmsoa
1i ssoxooem and» sue-cos me was» on Asvaoo
H“ aheaeu asoxooue postage uo scavefi>eu teens-pa use sees eveasoaeo .0 ug<u esav mud-sea me use >:H mmwwmmwmm
madam<mx
mmnmo moH>mmm
=u<m
veuevsoxoen «can: ends «0 emavceouea eueHsoHeu .n ug<u x\\}/J7
_
eoo
A<eoe
esdu edema noose Hevou emeue>e eveasoaeu 0440
.3
H‘
moHem
cease ueHHov Geo AoHVmHoo
ucsonuso nesovuso mo coaueabeo vueuceveemww ”wwwewnmmmmfluw waw meaeseusa coaeaoeo 9009 case zoow<a
.m nuevuoeu voucuuaoa we .o: deuce Advooxuo
_ coausaoeucn n.oo: Ho .02 mooxz
moHem ausoxoosu ago “svoaeoma
boo eeHee henna Geo AHNVmHoa
easy eaoho A<xmoz monotone vexoemu you vac» nee-o Hevoe Acvonpomm
house Hesse: nonsense mo coaueabep caduceus use sees eveHsoHeo .N uq<o nefiuomeveo mucusesca no .0: Heuoe omsz
_ veneeooun wcuen on :oauoaoeucH OzoaH
mxHa meamzH
uhu<zum
me
me uneaeHe esdu eofihhee uesoveso eeeHsoHeo .H ua<u
.02‘.‘ .Othu 002's 2.. “08:8 .0.H3H‘U >fim ZOHEEUQQ m2

 

132

Activity Block 1 calculated a customer service
penalty time, T3, that resulted when a DC stocked out
of tracked products during the past quarter's activities.
T3 was added to the averages of the other customer service
time elements, T1, T2 and T4, to arrive at a total aver-
age order cycle time (TOCT).

According to the math model specifications, T3 was
calculated for each inventory category and then a weighted
average, based on total, tracked product case sales, was
developed for the DC. Data base variables DCIS(l),
PRCTDC(3), PRCTDC(4), and ITNPC were used in this activity.

Activity Block 2 calculated the mean and standard
deviation of the customer normal order cycle time (NOCT).
The NOCT had been defined as the sum of the averages of
customer service time elements T1, T2 and T4. This activ-
ity used data base variables DCIS(21) plus DCIS(9) for
the mean and DCIS(lO) for the standard deviation of the
NOCT.

The mean and standard deviation of customer out-
bound transit time, T4, was calculated in Activity Block
3. DCIS(ll) and DCIS(lZ) were used for the mean and
standard deviation of T4 while DCIS(21) contained the
QTD order sales. Both Activity Blocks 2 and 3 used a
computer library function, SQRT, for computing the
standard deviation.

Activity Block 4 combined the mean NOCT, in data
base variable DCIS(9), with the penalty time, T3, to

develop the average total order cycle time, DCIS(7).

133

Block 5 developed another measure of inventory
stockouts. This measure was the percentage of tracked
product case sales, PRCTDC(4), that were backordered
for all inventory categories, ITNPC. The measure was
stored in data base variable DCIS(13).

Activity Block 6 calculated the mean and standard
deviation of the delay with which the tracked products
were delivered to customers because of product stockouts.
This activity used data base variables DCIS(l4) and
DCIS(lS) for the mean and standard deviation of the
delay plus the total number of product stockouts, PRCTDC(1),
for all inventory categories, ITNPC. This routine also
used the SQRT function.

Activity Block 7 calculated the proportions of the
DC sales dollars that were delivered to its customers
within a NOCT of three, five, seven, nine and eleven
days. Similar proportions were calculated for DC sales
orders. The data base variables used in these activities
were OCTDIS(l) for the DC sales dollar proportions,
OCTDIS(2) for the DC customer order proportions, DCIS(16),
DCIS(21) and IREGNO.

Activity Block 8 accumulated the DC's increment
1x3 a measure of the domestic total average order cycle
tzime, DOMAST. The average was a weighted average based
CH1 customer orders, DCIS(21). The DC's total average

(DCT was retrieved from DCIS(7).

134

Activity Block 9 calculated the total average
reorder lead times for each DC-MCC link associated with
the in-solution DC being processed. The reorder lead
time was composed of the DC to MCC reorder transmission
time, T1, the reorder processing and preparation time,
T2, the time that an order waited to be shipped from
the MCC, T3, and the MCC to DC shipment transit time,
T4. The data base variables used in this activity were
DCMCC(l), DCMCC(2) and NMCCS.

Activity Block 12 was a link to the MEAS routine,
EXTRAP, that developed additional measures of inventory
characteristics. Block 12 signifies a return to the
M&C end-of-quarter (EOQ) routine that called this sub-
program.

The next major component of the MEAS subsystem is
the extrapolation of average inventory characteristics
resulting from the activities associated with the pro-
cessing of tracked products. This routine generalized
or extrapolated the average characteristics, which it
calculated, to the total product line. If the total
product line was used, then there was no extrapolation
necessary. The only necessary thing was the calculation
of average characteristics. The utilized data base
variables are shown in Figure 37.

Activity Block 1 of Figure 38 calculated the modi-
fier which was used to extrapolate the inventory charac-

teristics for a specific inventory category. This

135

15.26.: souvenoaeg hues—guimn ensur—

esausou .eehseees eeEee a: o» Suez .& zmamm v

meanewu; :oaueaoceg 3339309328 bovcethuu$m eafim

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

nefnomoaoo bonnet: smacks» moo.“ .Mmmflv _ moH vevebeufilefia A309?“ \ I
neuevuoeu eunuch—teamed» 95 vauopbmm
38x03. 98 A3885
aces—peek: omega: veueaoaehxe on 3:808
32693 oexoeuu smacks» goo.» . a . «Bamboo
ammo
>zH
bows; ounce ensue»- e.aosuo.a eueaoaebkm aim $55
.3
P >2H
9&5 seduce: hams-o 5 3.5m
8.5.85 8 8.82. . 8.68s Snack—aha 3.5 t 7
. .n . ”Saga, maozmoonzm H:
homo»: 5 828.8 823.3 S. .88.... @
Emma
95980.8
eueouoeu nuances-edge one 3.6203» 332?me .u 2.5m
fl eeeo hen oHoe spoon no anon mumuo
mango: :3 3:33:73? A3095
eosefneaueheno E0893 suspend bomeueo no .0: H309 3:93
3:333 have-55 35 eueHerBke 3 seafloo- efi eve—".670 .H “S Em economwswunmouvwnvowuhwflw memmm
«u coeeeooun when on 533305 0203..
9:55
eeduomeaeo get: .34 eeeoehm {EH
33:86:30 5.8.235 on 33°93 3.58

ZOHEHMUWmQ @242

136

category modifier, CM, was calculated by dividing the
total number of products, PRCT(4), that an inventory
category was representing by the number of sample tracked
products, PRCT(3) minus PRCT(Z) plus one, in the category.
The use of the modifier accomplished the same thing as if,
for instance, the number of stockouts for the tracked pro-
ducts was divided by the number of tracked products to get
the average stockouts per product. This average would
then be multiplied by the total number of products.

Activity Block 2 extrapolated the number of stock-
outs, PRCTDC(1), and single-product reorders, PRCTDC(Z),
for a DC's inventory category. The basis of extrapola-
tion was the multiplication of the tracked product stock-
outs and reorders by the CM.

Activity Block 3 extrapolated the tracked products'
average investment. This was calculated by multiplying
eeach of the tracked product's time-integrated inventory
in case units, PRDC(3), by the cost of goods sold per
case unit, CGSCS,and CM. The results for all tracked
products were stored in DCCOST(6). DCCOST(6) then con-
tained the extrapolated, time-integrated average invest-
ment in inventories based on the products' cost of goods
sold. This figure, DCCOST(6), will be later multiplied
by the daily inventory carrying charge, DICC, to get the
cost of holding inventory at a DC.

Activity Block 4 followed basically the same pro-
cedure as in Block 3 except that the average case units,

in data base variable PRDC(3), was converted to an

137

extrapolated, average cubic IOH using data base variables,
CM and CUBCS.

Activity Blocks 5 and 6 identify the activities
of processing all tracked products in an inventory cate-
gory, PRCT(3) minus PRCT(Z) plus one, for all inventory
categories, ITNPC. Block 7 indicates a return to the
MEAS service (SERV) routine that called this routine.

After processing the measures of service and doing
the necessary extrapolation for both service and costing
purposes, the next components are the MEAS cost routines.

The first cost routine is graphically presented in
Figure 40. The data base variables are presented in
Figure 39. The purpose of this routine is to calculate
the cost of outbound transportation from the in-solution
DC, IDCNO, to its assigned DU's.

Activity Block 1 initialized data base variable,
iJCCOST(l), to zero. This variable will be the accumulator
of the total DC outbound transportation cost for all DU's.

Activity Block 2 used data base variables, DU(8)
and IDUNOl, to see if the DU was assigned to the DC being
processed. If not, then the next DU was checked for
Processing.

Activity Block 3 checked to see if the DC was a
EMS-P. If it was,then a rate correction factor was set
‘afllal to something greater than one in Activity Block 4.
The rate correction factor was used to modify the out—

bound freight rates for the higher costs of shipping

138

save.“ :00 fledagonhfldhlr Eagles at
endusou hudrauoe uevhdsvluoluce 01: e» shoved
eon. on as ..=n Ha. sausage saga
ouoo noda.ouon-:uss engages. confines-o

anus on.ua use gnausou s.oo case-suuauceta ucsonsso

move-u coda-oakauel sues acesnane ceHooa one no pew
com e on em

:oa».osc
-«uon .uqr us..a«n. sosooa you can . as as ea .o. o» .cassoa

.uuaoee nose-osuduo- os.u unsansouqa secede.» eon

eeoeu codueaton
oozeuu ueaeaveuec around: 0» on no veneeooun unease smoocm

asses.» u..s cuss-oscsuoa .s-u nods-stuauaaua nos.«som.z

uo endanaasu o no you eefien
unwdel nab use .eoceaeav hesnwdn .uovuem coauoemtoo each uem

ecaunou we. ea: .uur on endanaasa

a-ea ease veueauowec o» oo

muoam a so so“ mean»
unwaes aha use eoaeueao hisnwan .uouoeu co«uoeuuoo ea.» pew

mtoom e ed on «a com

no reason. you .qoue ..oa an so: .« so CH

nee-eooum modem on you e.:o Has eeeoesm

nods-«u.» unoo coauqaeoauauua unsonsso oasaaauch

v.00 coda-auoaeceuu vcdonvso 0o encaseaeo

 

 

 

      

n .gsrte :oH.se:uMa» unco codueuuoahceua pc:ODDDOIo.on eudmam

 

one. so“..stnanccss unconsso on “seaweeoa

mhbmpbo
n,.o¢u rec econ «scandzn oeaooa Uom umqoom
a: sonvu 93
eon-enap :Q-OQ hmma
m2 unused :o«-oehuoo even enhunuo aux
#4004

m.m<> W3m<mx<> 902ng an

no AAbh
.m paw

weaneuoud wcaen n.3u uo .o: Heuoe who:
only noueflsaae we use» mdmrh
transact :nx chooses“ eueu Hoax vamua
vauwcos sq. :necsocd east Heem Anvmwo
u:¢Hc«.eooo .9. osp.ssa> Asvaoa
.uoHCAeaooo :ex sceoncou Amvmoo
Cram «6; e.at n+.cdrumoc :D: Hecofimem Amlxxzwmo
5 1:8,: 3.... 9.23012 .3 122321 2 imimo
cenaezohd mason seamen mo .02 DzwfimH
was.» “seen: new Aaromsoo
meflen .LM oeu unVHm Aoflvao
ra.en .oH as; no ocaauAHsm Anflvzm
.m z eorelmfio asanwdc maOQi ANHVDQ
encasmvo learns: mu ecaauaflmm Aauvpo
useslawnmm we; 4 echo on nmvmuq
@/ Newmmefl;hm to; 3203...; is: Boson “Ozuaw
.N ucoacxwmme UQ n.3Q Arise
no setup. wsfxs «too we Haaucouom HOZUQH
Mia scone ucwsn no coauzmonICH oquH

webmzH

gmgxfi.
3535:“

onekaummo mx<z

 

 

 

Fmoo
pmo

 

 

139

small partial orders from the RDC-P. Activity Block 4
also retrieved the RDC-P to DU shipped weight and high-
way distance. These activities used data base variables,
DCP(8), IDCNOl, IDUNOl, DU(12), DU(16), RDF, DIST and WT.

If the DC was a full-line DC, then Activity Block
5 set the rate correction factor, RCF, to one plus
retrieved the weight, DU(15), and the highway distance,
DU(ll), for the DU being processed, IDUNOl. The retrieved
weight and distance were stored in DIST and WT.

Activity Blocks 6 and 7 checked to see if the amount
of weight processed over the last quarter might have
warranted the use of negotiated freight rates. The
assumption had been made that if the weight, DCIS(17),
was large enough, then the DC would have negotiated for
cheaper transportation rates for supplying its customers.
The modifiers were developed by region. Therefore, the
negotiated rate modifiers, OBTNRM(1) and OBTNRM(2), were
picked up for the region being processed, IREGNO, if
enough weight had been processed over the last quarter.

Activity Blocks 8 and 9 did similar activities as
Blocks 6 and 7. If the DC was a PDC, then it was assumed
that the amount of goods being shipped out of the PDC
warranted pooled or consolidated shipments to the DU's.
These pooled shipments, also referred to in the OPS sub-
system in reference to the calculation of the customer
service time element T2, were assumed by management to be

dispatched in short enough time in order not to hurt

140

customer service seriously. The data base variable,
POOLFC, held the PDC rate modifier. This rate modifier
was less than one. Activity Block 8 also used data
base variables DCP(8) and IDCNOl in determining the
type of DC.

Activity Block 10 calculated the outbound trans-
portation rate per pound using regression equations based
on the highway distance, DIST, to the DU from the DC.

The regression equations constant "a" coefficient, DCP(3),
and variable "b" coefficient, DCP(4), based on distance
develOped the basic rate. This rate was then modified
with rate modifiers OBTNRM(1), OBTNRM(Z), RCF and POOLFC.
In addition to the above modifications, the beginning
base year rate, that was the direct output from the
regression equations, was also modified by an annual
increase in the rate based on the year of simulated time,
IYEAR. These "real" rate increases were stored in data
base variables DCP(S) and DCP(6) for the potential
DC,IDCNOl, being processed. Finally the rate was multi-
plied by the total weight, WT, shipped from the DC to

the DU and the result added to DCCOST(l).

After all the DU's had been processed, indicated
by data base variable NDUS, then the routine returned
back to the calling M&C end-of-quarter (EOQ) routine.

Figure 41 shows data base variables associated with
the routine for calculating the inbound transportation

cost from the MCC's to the DC being processed.

141

esausom vuou soduevhonuceua unconsHII.~: eusmam

33%. actual?!- 3: 3 53.x

and .2» 3 vein £8: 3. 58.3» 83

eefiuomeueo amass: cam now eueoo scavevuoanceuu unconcd eveasoaeo

can 8: H1 8.88-8:

Effie. gsfc?io 0e: 3 53s.

8.. 35 3 8.22 38: S. 58.5 83

eeduomeueo amuse: com you eueoo souvevuooeseuu masons“ eueHsuHeo
83H 8: a aaooousioom

8a a 3 8 3 8. 3 x86

eHneaush aeoo scavevnoceseuv vouched on eeaaeavdoH

v.8 55%.: 1.895 8.8: 338.80

 

 

$8
:3
83

 

 

e
\D

 

a.

 

emoo
amH
QA<U

e
.96

mHAm<Hms>
mNHA<HhH2H

 

 

 

 

 

 

 

weanedud> coaueasoaeo veou coaueuuoanceue unconcHII.H: eusmam

unoo scavevuomeseuu canons“ on Amvemoooo

 

22.50

.3895: 23!. 09 co .oz 525
82%.»... 232. 02 co .oz 50%
~83

qum<Hms> mnozmoonzm Hm:

.t. ous-8 sounds-83 823

.3... 539C 002.8 88

ecoscmaene one + ed»» on onmon

83.8.3 9:3 .8". on H3238 853

8.38.8 ~53 on coauflouéa 983
$35

onemHmommo mx<z

 

 

 

 

hwou
hmH

 

 

 

 

142

Activity Block 1 in Figure 42 initialized data
base variable, DCCOST(Z) , which was used to accumulate
the total cost for moving the weight for the MCC-DC
links. After initializing this variable, Activity Block'
2 checked to see if a PDC was being processed. This
checking used data base variables DCP(8) and IDCNOl. If
a PDC was being processed, then Activity Blocks 3, 4 and
5 were processed. If not, then Blocks 6, 7 and 8 were
processed.

The reason for separate blocks for the PDC's and
RDC's was that the PDC generally shipped in higher weight
categories when they dispatched shipments. Therefore,
Block 3 used higher weight categories for accumulating
weight and calculating costs. Blocks 3 and 4 used data
base variables DCP2, DCMCCl, IVOLP, IDCNOl and NMCCS.

Activity Blocks 6 and 7 used data base variables
DCP2, DCMCCl, IDCNOl, IVOLR and NMCCS. After processing
all the MCC-DC links, this routine returned to the M&C
EOQ calling routine.

Figure 44 shows the major activities associated
With the next major component of the MEAS subsystem. This
component calculated the cost of preparing a customer
order for shipment. Activity Block 1 cleared variable
DCGOSTB) , shown in Figure 43, for accumulating the DC
throughput cost.

Block 2 determined the size of DC, using data base

Variables IDCNOl and' DCIS(8) . Given the DC size, Activity

1.413

meanoand> soapeasoaeo anoo vsnnwsonaeun.m: enough

ounce usanwsohnv on Anvemooon

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

webmsbo
ecaasom :owpeasoaeo vuoo vscnwsougeuu.a: enemas emou
abmmooomme
53.3." hvdbgoe kegs—7.3013 ow: op showed a A)!
.3
smoo
me
eueoo asngwsoucv on eveHsoHeo Qg<u
.n
\q
_ mNHm
enae on endsheveo on
.u 8% on B :8 sadness. oases
« A eeHee a: mac Amavaon
noveoauoa onus on vamHoa
mmqm<Hm<> oeeeeooum mason once on Heaasevom HoonH
eeanennep ueoo vsmnmsounu on enwaedufisH mNHA<H9HzH oenneooud mcaen on soavsaoensH ozuoH

 

 

 

ounce asunwsounv on eveasoaeo enema

onsmHmommo andz

144

Block 3 calculated the total throughput cost, DCCOST(3) ,
for the past quarter's activities using data base vari-
ables DCIS(17) and THRUPC. Block 4 was a return to M&C
EOQ.

Figure 45 lists the variables associated with the
cost of transmitting and processing an order up to the
point when it was physically prepared for shipment.
These communications costs, which are accumulated at
the DC stage, are allocated to the DC on the basis of
domestic, regional and DC fixed and variable cost fac-
tors. The reason for the three cost levels was to
allow for the flexibility of processing the order on
the basis of decentralized, regional and/or domestic
systems.

Activity Block 1 initialized the DC variable that
accumulated the total communications cost, DCCOST(4) .
This block also set to zero three other data base vari-
ables. These three variables were FC, the total of all
fixed cost elements, VCO, the total variable cost per
Order, and VCL, the total variable cost per line item,
for all three geographical bases.

Activity Block 2 determined the DC size and type.
This activity used data base variable IDCNOl, DCP(8)
and DCIS(8) . Activity Blocks 3 to 5 calculated the
total FC, VCO and VCL. To develop these totals, data
base variable IREGNO, COMMC, COMMCR, REG(17), COMMCD

and NUMDCS were used.

145

ecausom codaeaseaeo peoo esoaueedosasoouu.oa euswdm

ecdasou unabavee housesolucauce 0%: cu seduce

pace eccdaeedsoaaoe on nevov evedsefieo

eves: canneuwoew
Has you ecaa see pace e.co«uee«csifloo ennedneb eveHseHeo

suds: oanneuwoem
Has you geese neg pace e.:owueed:sssce eHneaesr eveasedeo

sauna canmeuwoem
cause-cc use seamen .09 new vece e.co«vee«:slfloe eendu eeeHseHeo

ooh» use euae on eadnheveo

mean-«a pace Boogeedaie on 3.33.55

eeoe e.co«veedsallx.un easaseaeo

.m

.N

“NHA<H9H2H
O H ,

 

 

 

 

 

 

 

smoo

 

 

mmwh
w mNHm
on

 

r

 

 

mHAm<Hm<5

 

once n.:owueo«csssoe on

evens cow Add new e:«H\veoe ue>
eves: oem Has you hecso\veoe ue>
suds: oem Has sou vece cendm

meanease> ocfiusaceaeo veco ecodaeefioossoolu.nc euswam

Svemooeo
webmebo

40>
00>
om
Hdooa

 

mmqdemds moozmwonzm HEM

seamen Leo e.oo soausacnoca we .0:
Diocese-av 38 5338-5 so .2.
eeeneeouc waden ccfimeu mo .02
soaeeausw eeae on

eeHee scone aha

cease coda ago

uoueeu veoe cowueenosisoe eaveesoo
noveeu pace coapeeassnsoe Hecoamem
cocoon once souveeaosssoe on
useawaeee 8m + one? on
veneeecua Medea ecoe on deduceuom
veneeoohn moden on sowvoaoeIsH

onsLHmomma

$38,.

2388
38.048
8888

82:8
5:60

SEE
863

mabAZH

 

 

 

 

 

 

 

 

146

Activity Block 6 calculated the total communica-
tion's cost, DCCOST(4) , using data base variables FC,
VCO, VCL, DCIS(21) and DCIS(ZO). Block 7 identifies a
return back to the M&C EOQ routine.

The calculation of an allocated facility cost per
quarter is graphically presented in Figure 48. This
component's purpose was to prepare an allocated, capital
investment for each quarter in land, building and equip-
nment. Activity Block 1 cleared the DC variable, DCCOST(S),
that was to contain the allocated investment. Block 2
identified the DC size and type using the data base
variables DCP(8) , IDCNOl and DCIS(8) . The amount of
investment was assumed to vary with the size and type
of DC.

A further assumption was also made concerning the
proportion of the total investment that was made in
equipment and in the land and building between large
and small DC's. This last assumption was the basis for
Activity Blocks 3, 4 and 6. Block 3 distinguished
between the size of DC's using data base variable DCIS(8) .
Given that a DC was classified as being in a small cate-
gory, then the ratio of equipment to land and building
inVestments was low. The rationale was that the smaller
DC ' S were most likely to have less automated equipment.

Activity Block 4, therefore, calculated the allo-
cated facility cost, DCCOST(S) , using the small ratio

and data base variables INVEST and CLF, a cost-of—living

147

838m 53336 3.8 333.5%? .53...

esavsce hvd>dpee sensesvluoluce ow: cu chsvex

eaves
8333 3 35.35. 8 .33 e53 3.8 333... 33:38

ecuasoh on euae emuea

essence huahdpee neauesouuoaese we: 0» unseen

one-u

manuaasn 0» oceanfisce on Haese modes aeoe hpuaweeu eueaseneo
hhomevee eeae ewuea ca ea on u“ eee cu xoegu

end» use ooh» on endsheaen

.353.» 3.8 3333 8 33.333

pace sesaso.e eoe.ooHH. ea .3.H=efl.e

 

 

 

 

 

 

 

 

mNHm a
wank on
:Emth
N a
mmqdem<>
MNHA<HHH2H
.a

 

i emo<m v

3.8 3333 8

noveeu usabaa no 3.00 on

euenaoo ace-veesnd m>e on
succeeds“ euae on

usescmaeee one + enhv om
veneeeoho modes eeoe on Hedusevom
eeeeeooun waden on sonusaoech

onamHmummn

.333; 533.38 3.8 3333.343 .53...

3 :3.88
$2.50

he
amaze
2:38
3:8
853
983
acres

mx<z

 

 

 

 

emoo
o<m

 

 

 

 

148

factor for the potential DC location. Activity Block 6
used the same data base variables except the large ratio
of equipment to land and building investments was used.
The ratios were built directly into the routine. Blocks
5 and 7 identify a return to the M&C EOQ routine.

The calculation of the cost of carrying and handling
product inventories is represented by Figure 50. The data
base variables for this component are listed in Figure 49.
Given the extrapolated, DC average investment, calculated
in the MEAS EXTRAP routine, Activity Block 1 calculated
the cost of carrying or holding inventories, DCCOST(6),
using the daily inventory carrying charge, DICC.

Activity Blocks 2 and 3 calculated the cost of pre-
paring multiple-product reorders for shipment dispatch at
each of the supplying MCC's for the DC being processed.
These activities used data base variables DCMCC(l),
MCC(3), NMCCS and DCCOST(6). DCCOST(6) was used to add
these reorder costs to the already accumulated inventory
carrying charges.

The cost of processing the reorder from the DC to
the MCC was not included in this routine because it had
already been included in the DC communication's cost.

The rationale for this exclusion was that, with the
increased use of computers, the placement of product
reorders has almost become a by-product of processing
customer orders. In addition, if the decision might be

to exclude the MCC order preparation costs at the DC

149

.533 53.338 3.8 Epchl6n 95»:

838.. 83.3.3.2. us. 3 5.x

3.3 8.18 3. 3.6.2» .33

auuvuoou vonbonnroadavusa you uuoo hounoou ovqasuddo

I3 UUIIUQ HH‘ .8“ 0.00 ROER QGOOORL

unuanopna usahuhao uo 0.00 on» ounasuauo

acted on a an nhovsobna msfihhhao and maddest: uo when oauasbado

 

 

 

 

 

 

 

 

 

moanaaud> nowadasuddo uuoo hhovcoantlom: oudwdm

uuoo mucusokcd on onemoouo

anon uncanny 00:

.8282. 33.32. 3 6..
soapsaouusd u.oo: «0 .oz
owudno wcahhuao huoucoan
vounooonn usdoa on soupsaonlsH

ZOHBmHmUmwQ

enmebo

Amoco:
Advooxca
mooxz
ooHn
onQH
meemzH

mx<z

 

 

 

 

 

 

 

 

150

stage of the model, then MCC(3) can be set equal to zero.

Block 4 identifies a return back to the M&C EOQ routine.

Supporting Data System

 

As mentioned in the introductory section of this
chapter, there are only three supporting computer activ-
ities for the MEAS subsystem. Figure 51 identifies the
logical activities associated with the FORTRAN activity
that had an effect on data base variables DCP(3), the
outbound transportation rate constant "a" coefficient,
and DCP(4), the outbound transportation rate variable
"b" coefficient.

The purpose of this program was to calculate a
matrix of highway distances for the potential DC's to
a sample of destination points for each potential DC.
The program's inputs included the city name, latitude
and longitude for each of the potential DC's and for
their sample destination points. The routine to cal-
culate the highway distances was the same one used in
the D&E "Distance Check" routine that develOped the
conversion factor from spherical to road distances.

The output of the run was a listing of the calcu-
lated distances with the rows of the matrix being all
sample destination points and the columns being the
potential DC locations. All elements of the matrix
were calculated and printed.

The output from this program was then keypunched

along with a weighted average freight rate for each

151

 

 

 

 

 

 

DIS‘I'HAT Calculate matrix of highway distances
® Routines to convert potential DC latitude, longitude
1.
CONVERT Convert potential DC latitude, longitude to rectangular X & Y
ORIGIN coordinate basis
LAT-IDNG
2.
Loop through all potential DC's
€135) Routines to convert sample destination latitude, longitude
3.
CONVERT Convert sample destination htitude, longitude to rectangular
BET I 8: Y coordinate basis
LAT-[ORG

 

 

 

Loop through all sanple destination points

 

Routine to calculate highway distances

 

cl,

CACL Calculate highway distance for a combined origin-destination
HIWAY
DIST'S

 

 

 

6.
@ “Loop through all combinations

 

 

PREPARE Prepare listing of results
RESULTS

it w ., mm

Figure 51.--Distance Matrix Routine

 

 

 

152

desired sample destination-potential DC link. This card
input served as the basic input into a system library,
univariate regression analysis program. The independent
variable was distance and the dependent variable was the
weighted average freight rate.

Straight line regression analysis was run on these
inputs as shown in Figure 52. Blocks 4 and 5 were manual
activities that compared the generated "a" and "b"
coefficients for significance and similarity. After the
comparisons, a final set of "a" and "b" coefficients
were selected for each potential DC location. Block S
was necessary to allow the possibility of using common
sets of coefficients for several potential DC's instead
of an individual set for each potential DC. The output
of this supporting data system activity was the prepara-
tion of the LREPS exogenous inputs, DCP(3) and DCP(4).

In order to determine the weighted average freight
rates used in the prior computer program, the third
supporting computer activity developed the percentages
of total weight shipped in specified order weight classes.
These weight class percentages were calculated in a
FORTRAN program from the accumulated weight sales of the
individual customer orders that had been summarized into
order blocks and written on a tape file in the D&E's
"Order File Generator." These percentages were then used
to calculate the weighted average freight rates from the

potential DC's to their randomly selected DU‘s.

 

153

 

.33... 83...... 3.x 3.3.:— émo 8.8...“ 2.3.

.33.... 3 .8

.3333... n e . 8 33.3. 3 3. 3.3 33..

33.33. .8. .33... 3.3338 n o . 8 33...... 8.980

:8 3333.3 3. 58.5 33

on you cannon 5333.3 cannon due £95.53 933

ups—«on
5333.3 ease. .3 use on Hexagon you wanna. soaeaoumou on

on you 353m 20333.8. me cause. 339$

5.333” on 73:33 noeo onoooum

.vsedoaueeo a a e on defiancevom @3256 o... 5595

 

nSu

_

 

 

 

A 9.58
3
Bad.
0“ . .
a
23......
3360
I: A

 

 

 

.n@||l
.Qul

A424
madam
on

g

9
m 95.53

 

 

 

 

.«

 

 

154

No block diagram is shown for this program since it
was a very simple summarization and division program. This
program also affected LREPS data base variables DCP(3) and
DCP(4). Although this last program was simple, it had a
very serious effect on the develOpment of the potential
DC's "a" and "b" coefficients. By changing the specified
order weight classes or the composition of the individual

customer orders summarized in the "Order File Generator,"

 

the "a" and "b" coefficients could be significantly

affected.

CHAPTER VI

THE MONITOR & CONTROL SUBSYSTEM

Inputs, Outputs and Data Base Requirements

The MONITOR & CONTROL (M&C) subsystem had the
responsibility of monitoring the activities of the
operating system plus controlling the feedback of infor-
mation that was used in making future decisions. The
monitoring activities included the supervision of the
sequence of events and activities over simulated time,
the scheduling of the fixed-time events, and the gate-
keeping activities associated with the inflow and outflow
of information linked to the operating system. The con-
trolling activities included reviewing and developing the
feedback responses plus updating scheduled changes into
the physical distribution system configuration.

The inputs into this subsystem came not only
exogenously through the gateway but also from the MEAS
subsystem. The MEAS subsystem passed to the M&C sub-
system the criteria for evaluating the simulated, distrie
bution plan that was in effect over the last quarter of

simulated time.

155

156

The activities of the M&C subsystem happened on
both a daily basis, when considering the Operation of the
D&C and OPS subsystems, and quarterly when considering
MEAS and M&C itself.

The OPERATING SYSTEM is divided into two main sec-
tions. The first section includes the supervisory activ-
ities which are grouped under the name of the model MONITOR.
The MONITOR controlled the order of and, in some cases,
performed the activities of the operating system. The
MONITOR is further subdivided into three sections. The
first section controlled the order with which activities
were executed. This subsection of the MONITOR is called
the EXECUTIVE. The EXECUTIVE had the responsibility of
picking the next imminent event from a file that was
chronological and first in-first out (FIFO) in order, and
calling the event activities that were to be executed at
that discrete point in simulated time. The role of the
EXECUTIVE in this model was handled by the GASP simulation
language subprograms. The GASP routines used in LREPS are
listed in the OPERATING SYSTEM section of this chapter.
These GASP routines are not discussed in detail.

The LREPS events, that were utilized by the GASP
EXECUTIVE in controlling the activities of the operating
system, are generally explained via a system flowchart
of LREPS data base variables, a logical block diagram of
activities, plus any peculiar programming techniques.

The programming languages will not be discussed since all

 

157

the events were programmed using basic FORTRAN instruc-

l)

2)

3)

4)

5)

6)

7)

8)

9)

The event activities to be discussed are:

DAILY-—the event to initiate the normal sales
processing activities for the day;
MONTH--the event to initiate the processing
of beginning-of-month activities;

QUAR--the event to initiate the processing
of end and beginning-of-quarter activities
associated with the operating system's
information input and output plus the
control of the feedback responses;

HYR--the event that basically initiated

the same activities as QUAR but did some
additional half-year activities;

YR--the event that was basically the same
as HYR but did additional yearly activities;
BOCYC--the event that initialized the LREPS
operating system for program execution;
EOCYC--the event that completed the activ-
ities of a simulation cycle plus generated
the necessary information to terminate the
LREPS operating system;

MCORAR--the variable-time event that
initiated the OPS subsystem processing

of a MCC order arrival;

DCSHPAR--the variable-time event that
initiated the OPS subsystem processing

of a DC shipment arrival.

158

51115; last two events are not discussed in this chapter
Since they were already discussed in the OPS subsystem.
In addition to the above subprogram events, the user-
written MAIN program and EVENTS subprogram required for
C§Zk£3£3 program execution are also discussed in this first
subsection of the model MONITOR.

The second subsection of the MONITOR is the section
dealing with the gateway of information into and out of
the operating system. In this section three quarterly
activity subprograms are discussed:

1) EOQ--the activity routine that supervised

the development of the model outputs plus
initiated the actual outputting of infor-
mation from the operating system;

2) EXOG--the activity routine responsible for
reading in the Operating system's exogenous
inputs;

3) BOQ--the activity routine responsible for
the initialization of endogenous data base
variables at the DU, DC and MCC stages of
the model for the coming quarter's activities.

The last subsection of the OPERATING SYSTEM‘S

MONI'I'OR is the activities associated with the scheduling
of the fixed-time events. Given that the model had been
defj~ned as a hybrid system that had both variable-time
and fixed-time events, this activity routine, called

SCH:ED, scheduled the fixed-time events.

159

The second major component of the OPERATING SYSTEM

is the model CONTROLLER. The CONTROLLER generated the

jfeaéedback responses that affected the future actions of

t;11€3 operating system. The CONTROLLER, which was composed

c315 FORTRAN, EXTENDED FORTRAN and assembly routines, had

t:11€ese Specific system activities:

1) REVIEW--the group of subprograms that

reviewed and developed the endogenous

feedback responses and which were

divided into these quarterly activities:

a)

b)

C)

d)

e)

DCSMOD--the activity of calculating

the DC and regional sales forecast
modification factors;

RWRC--the activity of calculating a
new regional total to tracked product
weight ratio for MCC shipment weight
extrapolation;

INVMGT--the calculation of new inven-
tory control variables used by the OPS
subsystem;

LOCATE--the facility location algorithm
for determining and scheduling any DC
facility system additions or deletions;
EXPAND--the scheduling of a DC facility
expansion given a DC was reaching its

capacity.

2) UPDATE--the following group of subprOgrams

that activated any exogenously or endogenously

160

scheduled activities for changing the

simulated PD system:

a)

b)

C)

d)

The SUPPORTING DATA SYSTEM has three computer activ-
ities for the M&C subsystem.
discussed in reference to the logical activities, the
programming language(s) used, the information and the
specific LREPS exogenous data base variables related to

the program, plus any peculiar programming problems and

techniques.

PUTDCN—-the quarterly activity of
making any scheduled DC facility
additions;

DELDC--the quarterly activity of
making any scheduled DC facility
deletions;

MODIFY--the quarterly activity of
making any scheduled DC facility
expansions;

DCDU--the quarterly activity of
generating the information needed
by the other LREPS subsystems for

the DU to in-solution DC links.

The SUPPORTING DATA SYSTEM programs are:

1) Data Preparation Run--the preparation of

the

operating system's exogenous input

tape;

 

These three routines are

161

2) DC to DU Packing Routine--a program for
the packing of the feasible DC's that
could serve each of the DU's;

3) DC X and Y Coordinates--the calculation

of the potential DC converted, rectangular

X and Y coordinates.

Operating System

As was mentioned in the first section of the chapter,

the M&C OPERATING SYSTEM has two main subsections. The

ffjxrst.subsection is called the MONITOR which supervised the

Eicrtivities of the operating system. The second subsection

i.s: called the CONTROLLER. The CONTROLLER reviewed and
developed the feedback responses of the Operating system
EDIJJS updated any changes to the PD system that were nec-

essary.

Mon itor

The MONITOR is further subdivided into (1) the

EiXJECUTIVE, (2) the "gatekeeper" of information into and

CNlt of the LREPS Operating system plus (3) its "fixed—

time scheduler." Each of these subsections are now dis-

Cussed.
Executive.--The EXECUTIVE controlled the order with

Vfllich the activities of the operating system were executed.

The role of the EXECUTIVE was handled by the GASP EXECUTIVE

Plus the user-written subroutine EVENTS. In addition, the

MAIN program routine for effecting computer program

162

execution is included as part of the EXECUTIVE since it
wists; indirectly involved in the order in which activities
(315 ‘the operating system were executed.

The MAIN routine had the reSponsibilities of (1)
irutitializing the unit numbers of the input and output
Etiflles, (2) buffering in the first group of customer orders
airlci (3) providing the link to the GASP routines and the
Lisseer-written EVENTS routine to begin program execution.
The end of computer program execution occurred in this
MAIN routine after one or more simulation cycles through
at lplanning horizon could have been accomplished. The
GASP feature of being able to stack a series of simulation
cycles was used to be able to run more than one cycle
c31xring any one execution of the LREPS operating system.

The GASP routines used in the simulation are listed
below:

GASP Main GASP routine.

DATAIN Routine to read in initial GASP data cards.

SET Routine to initialize filing arrays, update

pointer system, and maintain statistics on

the number of file entries.

FILEM Filed entries in file JQ of arrays NSET and
QSET.

FINDN Found event in array NSET with an attribute
equal to a specific value.

RMOVE Removed entries from file JQ of arrays NSET
and QSET.

PRNTQ Computed and printed time-integrated statis—
tics on the number of entires in a file.

SUMRY Basic output routine of GASP which printed
its statistical data.

163

MONTR Routine that provided the capability to
selectively monitor events for debugging
and program tracing.

ERROR Called when an error was detected in any
GASP subroutine except PRNTQ, SUMRY and
MONTR, all of which printed their own
error messages.

RNSET Routine that generated "seed" for random
number generator.

DRAND Routine that generated a uniformly distri-
buted random variate in interval 0 to l.

LOCAT For GASP IIA, this routine converted a one-
dimensional array, such as NSET, to a two-
dimensional representation.

OTPUT Routine that allowed LREPS to write out
additional, printed results of simulation
activities over a past period.

RNORM Routine that generated a normally distri-
buted random variate.

XMAX Routine that selected the maximum of two
numbers.

The above GASP routines were implemented on the CDC
6500. These routines are not the complete set of routines
available with the GASP simulation language. Only those
basic routines required to Operate the LREPS operating
system were used. Other statistical summary routines
were not used. A detailed discussion of each of the
utilized GASP routines is given in Simulation with GASP 11.1

Along with the GASP routines, the EXECUTIVE includes
the user-written subroutines EVENTS, DAILY, MONTH, QUAR,
HYR» YR, BOCYC, EOCYC, MCORAR and DCSHPAR. These discrete-

tine:events allowed LREPS to start and end the activities

*which took place in the computer model's operating system.

164

The EVENTS subprogram was called from GASP. After
being called, EVENTS called the next imminent event based
on the event code passed to it from GASP. After the
appropriate event's activities were processed, EVENTS
then returned to GASP. No system flowchart and block dia-
grams are included for this EVENTS routine since it was
merely a set of subprogram linkages.

The first event activity to be discussed is the
DAILY fixed-time event. Figure 53 identifies the data
base variables associated with this routine. In addition
to the LREPS data base variables, the variable TNOW that
GASP used for keeping track of simulated time was also
input into this routine.

Activity Block 1 in the logical block diagram,
Figure 54, for DAILY shows a link to the D&E routine
that generated the daily domestic sales dollar forecast.
No LREPS data base variables are associated with this
activity block.

Activity Block 2 is associated with the activity of
processing the RDC's in a region before the PDC was pro-
cessed. This initial processing of the region's RDC's
before its PDC was necessary in order to make sure that
all customer orders for both the PDC and any RDC-P's
'were processed before doing the PDC's end-Of-day activi-
ties. The data base variables that were used to see if
the RDC was in this PDC's region were DCP(8) and IDCNOl

‘which was set using DCIS(Z).

165

.528 5532 £26 583.3. 5E

unav50h uzddduo ow: 0» suave:

can». ondvuuoudu axon caduosom ov nuasvonoo onuvuunnfiu 0*: r» ow
3288.3 9:3 .85... n. 58.2» .53

coauabavOC baa-v dunno: a.oom onu uncoonn cu cadence men op 00
some 8338.5 3. 58...: 93

nodudbapon hdaav Hanna: u.onm 0:» uncooun 0» cadence mac 0» co
:oumou «fin» cw ad com aw 00a 0» xoosu

cam saga .vuudm n.0oxulnoumou Ge n.0a uncooum

Old» u an cannon one uncoonm

9300.8“ 0338.. has 393:5 3. 2.38.» mg on am

835.5%. has. 39.3» ea 55:08.5 3.33 3 158:

 

833.3, 93.88.... 255 38in“ 25E

voaaoooul undo: sown-m ozmamH
33893. was. 280 8 13.38 8.63

voonooonn wsaon on soupsaonnsH ozonH
wannabe
2.3 355. «o 3 e3 SE.

use-nude». com + omhu on Amcmun

:ouonaouund on Hawusouom Amvaun

u.oo codasaonusd no .0: muons:

«seduce soavsacnuad mo .02 mean:
ORDAZH

23%: ms

 

 

 

 

HhH>Hho<
nqud

 

 

 

 

166

After selecting a RDC that was in the region being
processed, Activity Block 3 is a link to the D&E routine,
SLSPRC, that initiated the processing of the normal daily
activities associated with an in-solution DC. The vari-
ables IDCNO and IDCNOl were passed to SLSPRC. Activity
Block 4 signifies the checking of all RDC's that were
in-solution. Data base variables NUMDCS and NREGS were
used for this checking procedure.

After all the RDC's had been processed, the PDC
for the region was then updated for its own normal daily
activities. The D&E routine SLSPRC was again called to do
this processing in Activity Block 5. The data base vari-
ables passed to the D&E routine were IDCNO and IDCNOl
after it had been set with IREGNO. IDCNOl was validly
set using IREGNO since the assumption had been made that
a region had only one PDC and, consequently, the region
number was also used as the PDC number.

Activity Block 6 used data base variable NREGS to
process all in—solution regions. It should also be noted
that LREPS was designed to process less than the total
number of defined market regions. This was the reason
for the variable NREGS.

Activity Block 7 is a link to the MONITORVS scheduler
of fixed-time events. This was the only location in the
LREPS operating system where SCHED was called since DAILY
always happened at each discrete point of simulated time.

The GASP variable TNOW was passed to SCHED from DAILY.

167

Block 8 signifies a return back to the routine that
called DAILY. DAILY could have been called from either
the GASP EXECUTIVE or from one of the other fixed-time
event activities.

The MONTH event activity is not discussed in refer-
ence to a block diagram or data base system flowchart.
The monthly routine performed two major activities.

The first activity is a link to the DAILY routine to pro-
cess the customer sales for the simulated end-of-month
day. The other activity includes the addition of a
monthly sales forecast increment, XINC, to TDSF, the
total annual domestic forecast. This last activity will
be explained in conjunction with the YR event activity.

The QUAR event activity is only discussed in refer-
ence to the block diagram in Figure 55 since it was
merely a set of linkages to other routines in the M&C.
Activity Block 1 is the linking to the event activity
MONTH to process the normal sales activities for the last
day of the quarter. After processing these sales, the
EOQ routine was called to develop the remaining measures
of output plus output the results of LREPS for the past
quarter.

Activity Block 3 then read in any exogenous inputs
into the LREPS common data base. After inputting the
exogenous changes, Activity Block 4 updated the PD system
for any scheduled DC changes plus any changes that

resulted from reading the exogenous input data. After

 

 

 

 

 

168

Routine to prwess quarterly activities

Link to routine to process the activities for the last nontb of
the quarter

Link to routine to process end-of-quarter activities

Link to routine to read LREPS exogenous inputs
Link to routines to nake DC facility changes

Link to UPDATE routine to develop DC to DU link information based
prinarily' on exogenous inputs

Link to routines to do PD system review activities based primarily
on endogenous variables

Link to routine to process begimnng-ot-quarter initialisation
activities

Return to GASP EXECUTIVE or other calling routine

F izuro 55.-Quarterly ment Activity

169

making possible changes to the PD system, Activity Block
5 called the UPDATE subprogram DCDU to develop DC to DU

link information that resulted from primarily changes in
the exogenous data base variables but also from changes

in the DC's that were now in solution. Activity Block 6
then passed through all the M&C routines that controlled
and develOped the feedback responses of the model.

Given the stages and the links between stages that
were now in solution, Activity Block 7. called the routine
to initialize the necessary endogenous variables to pro-
cess the coming quarter's activities. Activity Block 8
returned control back to the GASP EXECUTIVE, if QUAR was
called directly, or to the calling routine if it was
called from another event activity.

The HYR event activity was placed in LREPS for
future model flexibility. Therefore, HYR only called
QUAR and will not be discussed further.

The event activity for the annual processing of
activities for the beginning and end of year is called
YR. This routine linked to the QUAR event to process
the normal end- and beginning-of-quarter activities and
then performed three tasks. Task one was to increment
data base variable IYEAR by one. Task two calculated
a new monthly sales forecast increment, XINC. XINC was
calculated as a monthly average of the difference between
1381: Year's and the coming year's annual domestic sales

dollar forecast, TDSF. The last task was to modify TDSF

170

with the negative product of five and one-half times
XINC. In order to develOp a linear trend in domestic
forecasted sales that increased in constant monthly
increments of XINC, these last two tasks were performed.

The BOCYC event activity is explained in reference
to a block diagram but no data base system flowchart.

This event was exogenously set, along with the EOCYC event,
through the GASP input cards. The BOCYC event was used to
initialize the execution of a cycle through the planning
horizon which was limited in length to the time limit set
in the EOCYC event.

Activity Block 1 of Figure 56 initialized the LREPS
common data base for program execution by a link to
"EXOG." Activity Block 2 used some of the previously
read exogenous data, particularly data base variable
DCP(lZ), to put into solution the starting DC facility
configuration. This DC facility initialization was per-
formed by the UPDATE subprogram, PUTDCN.

Activity Block 3 then developed the necessary DC to
DU link information while the next activity block calcu-
lated the values for the beginning inventory levels and
inventory control variables for each of the starting DC's.
Activity Block 5 performed similar activities as those in
the YR event routine for calculating the monthly trend
factors for the first year's annual domestic sales fore-
cast. Finally, Activity Block 6 was called to process the

first day's sales activities plus begin scheduling

 

 

 

 

 

 

 

 

l7l

Beginning of cycle event activity

Link to routine to read LREPS exogenous inputs

Link to routine to nake DC facility initialisation

Link to routine to develop DC to DU link information

Link to routine to initialize DC inventories plus calculate
inventory parameters

Calculate modified annual domestic forecast

Link to routine to process first du's activities

Return to GASP EXECUTIVE

Figure 56.-Beginning of cycle 13mm Activity

172

endogenously the fixed-time events. Block 7 returned
control to the GASP EXECUTIVE.

As indicated above, the event activity EOCYC ended
the execution of the LREPS operating system for a cycle.
This exogenously set event was set one day after the
last simulated year of activity. No system flowchart or
block diagram are developed since the routine only set
the GASP variable, MSTOP, equal to a negative one in
order to stop cycle execution and then returned back to
the GASP EXECUTIVE. As was mentioned earlier, GASP
handled the stacking of simulation cycles through its
input data cards although the stacking of cycles could
have been done in this routine.

The only other event activities associated with
this section of the MONITOR are MCORAR and DCSHPAR. These
routines were discussed in the CPS subsystem. After their
program execution, they returned to the GASP EXECUTIVE.

InputZOutput Gatekeeper.--Figure 57 identifies the

 

data base variables and Figure 58 the logical activities
that were necessary for the development of the final
model outputs plus those activities that physically out—
putted the information from the LREPS operating system
for the Report Generator (RPG) system. These activities
were associated with what is called the end-of-quarter
(EOQ) activity routine.

Activity Block 1 initialized the variables needed

for a quarterly control record that contained information

 

 

173

8.35. 3333 iconic-:3 2.5:

sufugfigeaooezoog

Itzaiuhfikaluflilfifafinsg

couscou- Deloe 03er 3:163
snowmen neg—ence}: a sauna see..—

..8 E3531: 3. 58.5 no:

3:. 35% B 8333...: no :58 '3 Iain..- E: 3 is

eugenics-
u3=lv la 15:... 3.1.. 33 8 8e «.8 .33 E 5m

deco 1.3 so: no sen—Essa 312519 3 sends—x: a: co in

Pun wanna-ea 3:3! bade .eeoek.

conte- 13 case uc 3.3:: -.8 no: new-sen

need-anacon— neHe- .753: «one:
can: by even :89:

unseen—.13 c.2— 34 Among n03

«Anne: I: egos eeuee so verse: 33.3.1.6? sheaf—m

3 nose uueooum

53:58.: do
28! 35:8 his; .5 as «is... a like: Ex 3 .13

753.. 3.35... one. ton! PE 33 :23»! .3133

eons-e.— .eeaheecuuo-use «Ease use sash. ea I503:

 

3:215 0.5.63.5: ofll.R ens-2

“coy-H9560- .Ewaee cox-8

Eecwcoubcucebs cacao e334
0!: 30a nevus: eweueee out-um
Sconces v0.3-3:- uo .9: “as...

means .123. are 3

:19... £2... 8
3195 23' 8:
eeauoweveo Facet: we .Q: 3...

8 23-53....1. 33.. 95

22.—Ludo”...—

mEESO

 

m. .51
g

174

identifying this simulation cycle, NRUN, plus additional
identifying, alphabetic information, NAME(1) to NAME(6).
The variables used in the control record were from the
GASP data base which had been initialized with punched
cards. Activity Block 2 wrote this control record on
the RPG magnetic tape referred to in Chapter 2. This
last activity used an EXTENDED FORTRAN instruction to
buffer out this information.

Activity Blocks 3 and 4 looped through all the demand
units to develop exponentially smoothed DU dollar and
weight sales. The quarter-to-date sales, the sum of DU(l3)
plus DU(14) and the sum of DU(lS) plus DU(16), were aver-
aged with the past averages to arrive at new averages,
DU(9) and DU(lO). The alpha factor or smoothing constant
was set internal to these basic FORTRAN instructions. The
averages were developed for all in-solution DU's, NDUS.

Activity Block 5 used basic FORTRAN to reset to
zero the regional and domestic sales accumulators used
in succeeding activities. Data base variables REGSAC,
DOMSAL and REG(l6) were reset.

Activity Block 6 used data base variables DCP(8),
IREGNO and IDCNO to see if the present DC was in the
region being processed. If the DC was in this region,
Activity Block 7 shows the link to the MEAS subsystem
routines that calculated the measures of service and cost.
Data base variables IDCNO, IDCNOl and IREGNO were passed
to the subprograms to identify the DC and region being

processed.

175

Activity Block 8 then developed the total cost per
DC, DCIS(6), and per region, REG(16), using data base
variables DCCOST(l) to DCCOST(6) that were calculated in
the preceding MEAS activities. In addition, the sales
dollars and weight by region, REGSAC, were accumulated
using data base variables DCIS(16) and DCIS(17).

Activity Block 9 identifies the EXTENDED FORTRAN
subprogram that outputted important DC information in a
separate file for this quarter. The DC data base vari-
ables that were written on the RPG tape were DCIS(l) to
DCIS(21), DCMCC(l) and DCMCC(2) using NMCCS, PRDC(3)
using ITNSP, PRCTDC(l) and PRCTDC(2) using ITNPC,
DCCOST(l) to DCCOST(6), OCTDIS(l) and OCTDIS(2), WTACUM
using DCWB, DCMCCl using NMCCS and MCCWB. Activity Block
10 used data base variable NUMDCS to loop through all
in-solution DC's, while Activity Block 11 used data base
variable NREGS to loop through all in-solution regions.

Activity Block 12 then developed the domestic meas-
ures of sales, DOMSAL, and customer service, DOMAST.
These measures were developed using data base variables
DCIS(16), DCIS(17), DCIS(7), DCIS(21) and NUMDCS. DOMAST
was a weighted average total order cycle time based on DC
customer orders.

Finally, Activity Block 13 is again a means of
linking the LREPS operating system to the RPG system.
This activity used EXTENDED FORTRAN instructions to write

the entire LREPS common data base on the RPG tape for

176

this quarter. All data base variables except those
peculiar to any one of the major subsystems were written.
With this last output Operation, there were now three
separate files of information on the RPG tape for a quar-
ter. All three files of information would hOpefully
suffice any data analysis that was to be done in the RPG
system. Block 14 identifies a return to the M&C QUAR
routine.

Figure 59 identifies the logical activities asso-
ciated with the M&C routine responsible for inputting the
LREPS exogenous inputs into the operating system's data
base. In addition, the routine could also set data base
variables classified as endogenous in Appendix 1. The
procedure with which the variables were set was to
identify the sequential position of each LREPS variable
within the common data base. This assigning of sequential
numbers was called "cataloging the data base." As an
example, if there were a total number of variables in the
data base equal to ten thousand, then each of the variables
was given a number from one to ten thousand depending upon
its sequential position.

Given the cataloged data base, then the EXOG routine
basically read a "catalog" of information for each vari-
able or group of sequential variables that were to be set.
A catalog contained two tape records. The first record
contained not only the location or reference number of

the first data base variable to be set, but also the

177

.533. 325 .3535 «$58.8 use:
533.8 .325 go 8:1 3.. 9.3.x

nemoeno sevens am consensus on

so sopeoduca omsenc sevens am you

newness seesaw am usosemoxo use ma oee cu xoenu

scanner you ewoaepeo Has cusses» moon

3:. «.54 .3 mod-30 3.5

coupe-sous“ we moaepeo nose soeoenm

evened usosemone manna ca uses on esaveom

 

 

 

 

 

 

mmmoqmm

 

 

 

178

number of sequential items to be set after this first
variable. The second record of the catalog contained
the data that was to be read in. The catalogs were
grouped by the quarter in which they were to be read.
Given a five-year planning horizon, there would then
be twenty quarterly files of catalogs. The first quar—
ter's file initialized the total common data base.v

Activity Blocks 1 and 2 identify the EXTENDED
FORTRAN activities of reading a quarter's catalog of
exogenous inputs. Activity Blocks 3 and.4 are associated
with the testing of data base variables IUDFCZ) to IUDF(5)
for possible exogenous changes to the PD system being
simulated. If there were exogenous changes, then data
base variable PDSCHG was set in order to signal other M&C
routines that information associated with PD system
changes should be develOped. After these activities had
been completed, Block 5 of Figure 59 identifies a return
to the M&C QUAR routine.

The last activity associated with the inflow and
outflow of information from the LREPS operating system
is the beginning-of-quarter (BOQ) activity of clearing
or reinitializing certain endogenous variables in the
LREPS common data base for the next quarter‘s activity.
This routine was programmed in basic FORTRAN and ini-
tialized the data base variables listed in the output
section of Figure 60.

Figure 61 shows the activities associated with

reinitializing the variables for the different stages and

179

 

83.3. 9338 is?§.3 one:

”ragga-48913.53...

31v 03 eaafiH

goodness-«Egg

so? .Uu sedans» Duo-eases due 3303
so? Aces eases...—
..8 83.43.... 3. 58...: 93

oer-$38 get: fun g g

eed'u’eo PE" :8 53.35

his-ease have-.85 noes eeeeeum

32.3.... 38.3 :8 58.5 93

833...: 82.8.. 3.89... 3.33....

on 8.“ ago?!— vexoehu nose :89...

8 :5 .3. 923 82.8 3. 5.6.5 93

a; 00:18 8% nosed; 532...;

.23 8.18 no: .38....

swee- ua .0303- .8u nearer—er geese: fine ea 1.35
on «83531.3 nose .3095

:8 a 5.5.5 83

sonnets» on hue-secs: due 331.35

3 aces :89:

:33...» 388...... «.33 33.33 3 138..

dha
UHg
on a
O N Hg
:8
. 3H5
« «

 

 

 

 

 

 

 

 

 

 

 

 

e
‘D

 

 

 

 

 

 

 

eeanefne> hardy": Bakelgilooo egh

333.53. 3.7. 33 4498

3.8 E 33 «3.2.8 8.5..

8.. P. .388 .338

223...... 8.38 5.8885 8 “$85.:

. 3 28.5.:

Eels 03.8.... H33 95 Sign.

=8 83.33533 8 288..

.8593- ...7. 1.33 “.485.

3.8 E .33 3.833. 338:

.33 83.... 3.38 1.3.3. 838..

2.3 3.32. 8.59... 3.3.3 95 3:5.

9.8.8... 3.9.3..- ..o .3. 3.8.8

3833362. 23.! 8.18 .88

33333.62 .23... 8 28::

3.3828...— hv... 8?. .69. 3888

230.88.... .33.. 3d: 88 2588

3:. 83. 8 5333.... :38

8 .338

3:. one... 8 8338.5 2748

3... on...» 8 83:3ch 358

3... 83. 8 5338.... :58

.78..--33. 232. as $38

8 23-23333. 23¢. 95 $.38

.3233... .33.. 95 3:8

8 2.735333. .33.. 2e :38
mSmSo

nefBueaec b.3523 we .2 33. 0.2.5

338.... 3......» do .8 38 .82....

28%... 5393...... co .3. was.

:8: 53.48.... so .1. 865.

3.38.... 8.3 :8 .3 .2. 88.
28.:

285qu 93.

 

 

 

 

180

links in the PD system. Activity Blocks 1 and 2 initial-
.ized DU data base variables DU(13) to DU(16) using NDUS.
Activity Block 3 reset DCIS(l), DCIS(6), DCIS(7), DCIS(9)
to DCIS(21), OCTDIS(l), OCTDIS(2) and WTACUM to zero for
each of the in-solution DC's. Activity Blocks 4 and 5
set DC to MCC link data base variable DCMCC(l) to one plus
reinitialized data base variable DCMCCl to zero for each
of the MCC links, NMCCS. i

Activity Blocks 6 and 7 reset PRDC(3) to zero for ,_
all tracked products, ITNSP. The DC inventory category
variables PRCTDC(l) to PRCTDC(4) were reset in Activity
Blocks 8 and 9 for all inventory categories, ITNPC.
Block 10 shows that the above activities were done for
each of the in-solution DC's, NUMDCS.

Activity Blocks 11 and 12 reset the regional data
base variables REG(4), REG(13), REG(16) and REGSAC to
zero using variables NREGS. The domestic variables
TPDEM(l) for all tracked products, ITNSP, DOMAST, PDTCST,
and DOMSAL were reset to zero in Activity Block 13.
Finally, Block 14 identifies the return to the M&C QUAR
routine.

Fixed—Time Scheduler.--The last component in the

 

Operating system's MONITOR is the fixed—time scheduler,
SCHED, of events. As was previously mentioned in the

first part of this chapter, there are nine event activ-
ities, each with their own event code. Seven of these

event activities, all but BOCYC and BOCYC, were scheduled

181

endogenously within the LREPS operating system. Given the
assumption that LREPS would only process the workdays of

a simulated year, two hundred and fifty-two days, SCHED,
by means of NSCH, an exogenously set array of event codes
and days of occurrence,scheduled the next endogenous
fixed-time event for tomorrow. For instance, if today

was day twenty of simulated time and there were twenty-one
days in a month, then the event activity MONTH would be
scheduled for tomorrow. If the day was sixty-two, then
QUAR was scheduled. Figure 62 shows the basic activities
associated with scheduling DAILY, MONTH, QUAR, HYR or YR.
Block 1 determined the present day using the GASP vari-
able TNOW. Block 2 used TNOW plus NSCH to schedule
tomorrow. If "today" was not in the array NSCH, then the
DAILY fixed-time event was scheduled. Activity Block 3
stored the fixed—time event, using the GASP subprogram
FILEM, in the filing arrays NSET and QSET.. The fixed-
time event's attributes were the time of event processing,
and its respective event code.

Because tomorrow was always scheduled every day, at
any one time the maximum number of fixed-time events in
the GASP filing arrays NSET and QSET was two. An endo-
genous fixed-time event plus the end-of-cycle event that
was set exogenously were the two events. After scheduling
the next fixed-time event, SCHED returned to the M&C DAILY

routine that always called it.

 

182

 

335 .3338 .£.§I.~o .53.“

EBB... 9.5». a3 3.: 3. .53

:32 25:8 m3 m5: 5.8- 333 €25 23 5 «:25 33

Sub!» 8m as». 23.185.“ Sfiuaoae. 32.3%

33 79.35. 5 9.3.8.. .2383 23 26:38

9.5». 3.735 as: .938 3. 833

 

 

 

 

 

 

 

 

 

183 ‘

Controller

 

The operating system's controller is divided into
two major sections. The first section reviewed and
developed the feedback responses. This section is
called REVIEW. The second section changed the PD system

for any exogenously or endogenously scheduled PC changes.

in.

This section is called UPDATE. f

Review.--The first subprogram in the REVIEW section

"J Ll_’_ . ‘_04—
.
.l n .

calculated the DC and regional, exponentially averaged
factors for modifying forecasted sales. These factors
were based upon actual and desired levels of customer

service. The customer service levels were defined in

terms of average total order cycle time.

Figure 63 identifies the data base variables asso-
ciated with this subprogram called DCSMOD. Figure 64
identifies the logical activities in calculating the
sales modification factors DCIS(4) for each in-solution
DC and REG(l4) for each in-solution region.

Activity Block 1 determined the proportion of
dollar sales, DCACTS, that was delivered within the spec-
ified customer service time that management desired for
the nation, DAYCON. The proportion was interpolated from
the prOportions that had been accumulated in the normal
order cycle time array, OCTDIS(l). Since the management
parameter, DAYCON, was based on the TOCT, it was reduced
by the back order penalty time T3 in data base variable

DCIS(l). Then the correct set of proportions from

1.5}4

 

050—62 cauvdasuddu hovOIh andvdnfiudvo: uOHdmttos 0a?—

»fipfioa €25 58 8: 3 53:.

unaduou coaasaoolna Add nuanusu mood

arm Hqcodwou oomcuobc bdaduvcoconuo an: ovcasoauo

uoahcuu wand you
arm ouuanoaqo 1:1 chancel oowpuou uo flop-H Hudson cad-hoaon

common sou. naoooum

38 5338.5 3. .33....» 93

mum on conduo>¢ hHHuaucocoaHo so: ovcasodcu

hawk-av vuqH you arm ou-Hsoaoo

mxm you we»: on on channel cowbpou «o Hoboa H1990. ccunuovoa

on non. uncooum

agave.» Hacoeuou use on ovqasuano o» cusses

 

 

 

 

 

 

 

 

 

MUH>mmm
A<Dho<
mszzmpma

P

 

 

 

33.2; 53.938 .38.... 5333.3: 81min? 933...

.338 :oSaoenxi 3H8 1.3%... .4... 3:92
.83.... 838382. 8H: u... n1.3%.... and 338m
932: 53823.... 3d: 8 3748

22.50

vane-cone ucdon scan.» «0 .oz oauan
1.88.... 9:3 8 8338.5 E
non-cu
ooapuoa aqua»: on who‘ve
Huang

mmam<Hm<> msozmoonzm Hug

0.5.528 8.. + 85 8 Sing

«:5 a: £35.56 3.33. 3x5
coamou you coarhon no Herod condone Anvumu
3.3»... 5338.5 go 62 mg...

«.8 5338-5 do .2 8852

.81... v3.32. 33:33 8

2.3 .5an m... :8 8
usoauhunoun uddaov noun» goo: Auvanpoo
5.5.3. 8:8... So H33 «.8 =83

onhmHGUmmo mzdz

 

 

 

 

 

 

 

 

185

OCTDIS(l) could be selected, using DAYCON less DCIS(l),
within which the interpolation of the final proportion
occurred.

Activity Block 2 divided the DC's service propor-
tion DCACTS, by the regional desired level of service,
REG(S). Block 3 then exponentially averaged last quar-
ter's sales modification factor, DCACTS, with the old
factor, DCIS(4), to arrive at a new SMF for the DC. This
new SMF was stored in DCIS(4). Block 4 indicates that
the above procedure was done for all in-solution DC's,
NUMDCS.

After the DC SMF's had been calculated, then the
new regional SMF's, REG(l4), were calculated. Block 5
indicates that the region's SMF, REG(13), for the last
quarter, was first calculated. REG(13) was a weighted
average of the DC's sales modification factors, DCIS(4),
based on the DC cumulative weighted indices, DCIS(S),
and the weighted index for the region, REG(8).

Block 6 shows the activities associated with the
calculation of the new exponentially averaged regional
SMF, REG(l4). For both the new exponentially averaged
DC and regional SMF's, the alpha factors were built
directly into the basic FORTRAN instructions.

The next routine to be discussed is RWRC. The
purpose of this routine was to calculate a new regional
ratio of total product line to tracked product line
weight sales. This ratio was used in the-OPS subsystem

to determine the total replenishment weight shipped from

186

a MCC to a DC. Figure 65 shows the data base variables
involved in the calculation of these ratios. Figure 66
is the block diagram of logical activities for this basic
FORTRAN subprogram.

Activity Block 1 reset to zero an accumulator,
SUMWT, for the region's total customer weight sales.
Block 2 then checked the next DC, IDCNO, to see if it
was in the region, IREGNO, being processed. Data base
variables DCP(8), DCIS(Z) and IDCNOl were used in this
checking process.

Given that the DC was in the region being processed,
then its QTD weight sales, DCIS(17), were accumulated in
SUMWT. Block 4 indicates that all in-solution DC's,
NUMDCS, were checked for each region.

After the region's total weight sales had been
accumulated, then the total tracked product weight sales,
REG(4), that had been accumulated in the OPS subsystem,
was divided into SUMWT. This quotient, the new regional
weight ratio, replaced the old ratio in data base vari-
able REG(15). Block 6 indicates that these ratios were
calculated for all in-solution regions, NREGS. Block 7
shows a return to the M&C quarterly event activity.

The next major activity was concerned with the cal-
culation of the variables used in the inventory control
Operations of the OPS subsystem. These variables were
calculated according to the management specifications as

to the type of inventory control policy plus the policy's

 

187

83...... 53583 o3... 23.: 3.3.3.8.“. 2......
258.. 5338.3 3.... .23.: 1.3337... 93.:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

bis... .5». .35 8: 8 .553. fig 3.... 8a.. 2...... 1.3%.: 338.. .\J/
mSmSo
3.3m... 5330-35 3. £9653 93 a
O
o
8.5.
acumen no.“ 03..— »nudo’ («CH—Sade . 33 vouuoooua ”Son scam?" .3 .oz 28::
n 2.88.... 8.3 28. 8 13:30.. 828. 2.5.
6.8.8.... 8.3 8 5330.-.: oz8H Sufi:
fun 20333-5 ad- nmsobfi n03 a , .3330 33
.a .3... .t. 1.3.»... 95 18... been
H33 x>l
S 8.83:; 896082.. a:
8:2.
2...... H83 .23.... 8 £3... 98 3.358. .n .58.
a
scam... 5 on .3 can 0» x026 e
.N
on coaaaaouusa Loco 3000.5 9
332.;
.3... H38 8 3.356.. 3 .33...» 83.3.5 mNHsfieEH .523... 8.. + on... 8 8:8
2.1. 2...... H33 8 95 2.328

 

 

 

.352. 8 8.3.3.... 358

nod-u .538: vantage @8695 95 A393
9330.. .3333-..“ .3 .oz mama

fun .5333-..“ mo .oz 895:

.H
as... .332. Hague.” at: 3.1.1.33 3. ous—Sm % mSAZH

scam: no: :39...

ZOHEHMUQQ mg

188

respective parameters. Since all of a company‘s products
might not have been tracked, the management specifications
were set by inventory category and not by each of the
model's tracked products.

The data base variables used in this subprogram,
which used both assembly and FORTRAN routines, are listed
in Figure 67. The logical activities are identified in
Figure 68. This subprogram was called at both the begin—
ning of cycle to set the initial values and quarterly to
update the values of the control parameters from the
results of past sales activity. This recalculation of
the inventory control parameters was the basis for calling
this section of LREPS a dynamic inventory control model.

Examining the activities of this routine in detail,
Activity Block I checked data base variable PRDC(Z) to
see if it contained a negative one that would have been
set in the UPDATE routine PUTDCN if a new DC was coming
into solution. If it did contain a negative one, then
Activity Blocks 2 and 3 calculated the initial average
reorder lead times between this DC, IDCNO, and each of
its supplying MCC's. Data base variables DCIS(Z), IDCNOl
set from DCIS(Z), DCPl(3), PARM, MCC(l) plus a constant
T3 were used in setting this initial average lead time,
DCMCC(2). The initial lead time was calculated as the
sum of the averages of the reorder lead time elements T1,
T2, T3 and T4 for each of the supplying DC-MCC links,
NMCCS. Block 4 indicates that each of the in—solution

DC's was checked to see if it was a new DC.

 

 

 

 

CALC

INV
CONTROL
PAWS

 

 

 

 

l 8 9
NAME DESCRIPTION

INPUTS
DCIS(Z) Potential DC pointer
DCIS(5) DC cumulative weighted index
NUMDCS No. of in-solution DC's
NMCCS No. of inn-solution MCC's
DCPl(l) DC-MCC tracked product supply links
DCPl(3) DC-MCC T1 3. T4 factors
ITNSP Total no. of tracked products
ITNPC Total no. of inventory categories
TPDD‘K 1) QTD tracked product case sales
PRCT(2-7) Inventory category variables

DICC Daily inventory carrying charge
PARM Service time variance functions
MCC( 1) MCC T2 order prep tine factors
NWKDYS No. of workdays per sinulated year
CGSCS Tracked product cost of goods sold

VKEI mnoemous VARIABLES

Local

DEM DC tracked product avg daily duand

BUF DC tracked product buffer stock

I'DQ DC tracked product PDQ '

SLT DC std dev lead time

SRP DC std dev review period length

SPD DC std dev avg daily deaand

ORDCST Tracked product ordering cost

Common

IDCNO In-solution DC being processed

IDCNOI Potential DC being processed
OUTPUTS

PRDC(i) DC tracked product ROP's

PRDC(Z) DC tracked product S-level

PRDC(h) DC tracked product initial inventory level
DCMCC(2) DC-MCC avg reorder lead time

TPDEM( 2) Exp avg tracked product case sales

Figure 67.-Invontory Manage-ent Variables

Anna—er, AA“ _I
1.. '

190

scanned use-omens: huovcebrao..mo eunuam

bravo. m>HS8m .38 8: 3 E33.

a.ua coauaaoeoca nae smacks» coca

euosuoua vexoeuu Has smacks» nooa

Hopeaum n.uo=voaa nose-Lu eueasoaeo

:8 co 9:3: 83:5. "8 3o

coausaoe
coca wcasoo on so: ease you Horefi aboacebna aeaudcd eveaaoaev

382 H23 D352: 13d: .3 o: 3 x25
eHe>eH hhou:e>:« eueasoaeo cu ecausoz

hu«aod wanna: he ace-zaaceadeu
.35? 5t. 8: .5 .8288 ooze-.5 .5 28 33?..qu

hoaaod ended Leuhoea eees convene nexoeua on see cu xoesu

Nmom nee: 9038.3 .3 sea cu cannon

~moz use: oosuoun u« see e9 ecdueem

.822. 332 .8 «Son
aeouoeu uezuae baa: on: too nauseoun nexoeuu new «mom eoeaeoaeu

ho«H0d acouzeaceaaeu eons aoauoud peso-nu Ha ee- ov xoenu
unsound vexoeuu you cam use 8000- Leuusn eveasoaeu

. unease had-o onshore
use coated sea>eu clay v-eH «o ecoauewreo unsuceuu ecu-heuen

o unspent

nexoeuu nan» Lou nae-so haunt ensuebe o.oa on» eueflzoaeu

 

 

 

 

E 8 .5 3 $.69... .5 9.5%:- 8: .5 05:38
.sa
Am>maom on you nooavouu vexoeuu aHe eeeooum
Qg<u
eOa
A on coauaaoeucu soee aeoooum

 

qm>m4 oozeseo o«ueeeoo .nuosu0hn vexueuu omeue>e AHA-«vsecodum

 

 

 

n.uo coauaaonncq HA. gmsouAu noon

8 35 .ac 3?: 8: H1 @853 83

 

 

 

 

 

on: use owe... e
Near a e» Heaunca eueasoaeu
uq<u
ma 2 nonau naea Loose.» eu-ueve Heauacd uoxuoo eueasuueo .0. mm
o ..
. » mom
S .3333 35 unmask 8 so: 8 o: 3 .825
on coauaaoeund nose eoeoeum

naeueseued acuanoo muouce>=a eaeasoneo cu ecaasom

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

m.kg<
A<HPH2H
hmm

 

Pox>zH

 

 

 

191

In order to predict the level of quarterly sales in
the next quarter of simulated time, Activity Block 5
calculated an exponentially averaged total product demand,
TPDEM(2), for each of the tracked products, ITNSP. The
past quarter's sales activity, TPDEM(1), was averaged with
the old tracked product's prediction, in data base variable
TPDEM(2), to determine the new prediction. Again as in
other places where exponential averaging had been used,
the alpha factors were built directly into the FORTRAN
instructions.

After calculating the above predictions for the
entire domestic market area, the remaining activity
blocks calculated the specific tracked product inventory
control variables for each in-solution DC. Activity
Block 6 first determined the MCC supplying the tracked
product being processed. This activity used EXTENDED
FORTRAN to shift out the MCC number from DCP(l) using
the potential DC code, IDCNOl.

After determining the MCC supplying the product,
the next activity calculated the average daily demand
for the product from the DC being processed. The average
daily demand, DEM, was the product of the new domestic
prediction, TPDEM(2), the DC's cumulative weighted index,
DCIS(S), plus the reciprocal of the number of workdays
in a simulated quarter of activity which was NWKDYS

divided by four.

192

After the average daily demand was calculated, three
standard deviations were calculated in Activity Block 8.
SLT, the standard deviation of reorder lead time, was
calculated as the square root of the average lead time,
DCMCC(2), assuming the lead times were Poisson distri-
buted. SRP, the standard deviation of the review period
length, was calculated as the quotient of the average
review period length, PRCT(6), divided by the square root
of twelve. SRP's calculation assumed a uniform distribu-
tion. SPD, the standard deviation of daily demand, was
calculated as the square root of the average daily demand,
DEM. This calculation also assumed the demands were
Poisson distributed. These activities used basic FORTRAN
instructions plus the computer system library function
SQRT.

After calculating these basic values, Activity
Block 9 calculated the tracked product's buffer or safety
stock, BUF, plus its economic order quantity, EOQ. BUF
was the product of data base variable PRCT(7) and the
sum of SLT times SPD and DEM times SRP. EOQ used the
standard EOQ formula plus data base variables TPDEM(2),
ORDCST, DICC, and CGSCS.

After calculating the buffer stock and economic
order quantity, Activity Blocks 10 to 13 calculated the
reorder points used in the alternative inventory control
policies that were built into LREPS. Block 11 calculated

ROPl if the tracked product used a daily reorder point or

193

hybrid system. Data base variables PRCT(Z), PRCT(3),
ITNPC and PRCT(S) were used to determine the product's
type of policy. If the product used a daily reorder
point or a hybrid system, then ROPl, data base variable
PRDC(l), was calculated as the sum of BUF plus the pro-
duct of DCMCC(2) and DEM. At this point in the program,
ROP2 was also set equal to ROPl.

If the tracked product used either a replenishment
or hybrid system, then Activity Block 13 calculated ROP2
as the sum of BUF, the product of DEM times DCMCC(2) and
DEM times one half of PRCT(6). The calculated ROP2 was
then packed, using EXTENDED FORTRAN instructions, into
PRDC(l) along with ROPl.

As was similarly done in Activity Block 1, data
base variable PRDC(2) was checked in Activity Block 14
for a negative one to see if the DC being processed was
a new DC. If it was a new DC, then the DC's initial
inventory levels had to be determined. These initial
inventory levels, PRDC(4), were set in Activity Block
15 as the sum of EOQ plus BUF.

Activity Block 16 then calculated the standard
S-level, data base variable PRDC(2), used for all LREPS'
inventory policies. The S-level was the sum of EOQ and
ROP2. The above equation was also correct for the daily
reorder point system since ROP2 was set equal to ROPl

for that policy.

194

Finally, Activity Blocks l7 and 18 show that the
above activities were done for each tracked product,
ITNSP, and all in-solution DC's, NUMDCS. Activity Block
19 identifies the return back to the calling GASP EXECU-
TIVE activity.

The above inventory management routine is a module
that is hopefully general enough to handle the policies
of many companies. If the routine is not, however,
satisfactory for a certain company's operations, then
the module can be replaced with the specific policies
that the company desires. This substitution of a differ-
ent module was successfully accomplished in a test case
for LREPS.

The facility location algorithm, called LOCATE, is
probably the most sophisticated user-written routine in
LREPS. This subprogram was responsible for the scheduling
of the addition or deletion of DC's in the PD system con-
figuration. A basic assumption was that LOCATE would
only add or delete facilities but not add and delete
DC's in the same quarter. Depending upon the constraint
values, the review of the DC system configuration was
done, at the most, quarterly.

Figure 69 shows the data base variables involved in
this routine, while Figure 70 shows the logical activities.
This routine was composed of a number of subprograms.
Assembly, basic FORTRAN and EXTENDED FORTRAN instructions

were used throughout the entire routine.

 

 

 

 

SCHED

ADDS OR
DELETES

 

 

 

 

am 10)
am 11)
mam 12) ‘
Rim 17)
am 111)
mass
mus
DCASGN
ncwc
mow
mum
DCIS(6)
DCIS(17)
NDCADD

1J95

DESCRIPTION

Domestic constraints onpoff flag
Total inv for in-solution DC's
Max total inv. for in-solution DC's
Total inv for in-process DC's
Max total inv for ineprocess DC's
Dom no. of ineprocess add DC's
Dom.no. of ineprocess delete DC's
Max no. of in-process DC's

Max no. of allowable DC's

No. of in-solution DC's

PD facility changes flag
Regional constraints' on-off flag
Max no. of DC's allowed

Max no. of DC's that can be added
Max no. of DC's that can be deleted
Max in-solution DC investment
Max ineprocess DC investment

No. of in-process add DC's

No. of in-process delete DC's
Total in-solution DC investment
Total ineprocess DC investment
No. of in-solution DC's

Exp avg SMF

No. of in-solution regions

No. of in-solution DU's

List of feasible DC's per DU

DC dollar size capacities

GASP dmy of simulated time

Delmy time to add DC

Inpsolution DC total PD cost
In-solution DC QTD weight sales
Max no. DC's put in-process/quarter

KEY ENDOGENOUS VARIABLES

Local
RLCSMF
RLIST
DCSUM
NDCIN
Common
IDUNO
IDCNO
IDCNOI

Expected regional SMF

List of reg SMF's plus later eligible DC list
Eligible DC's sum of DU sales

No. of DC's in-process this quarter

No. of DU being processed
Inpsolution DC being processed
Potential DC being processed
No. of region being processed

Time of DC change + type change

No. of in-process add DC's

No. of in-process delete DC's

Total inrprocess DC investment

Total dom ineprocess DC inwestment

Dom no. of inprocess add DC's

Don no. of ineprocess delete DC's

Dom no. of 111-process DC's added this quarter

Figure 69.--Facility Location Algorithm Variables

196

" ‘Vlllllll ‘11.

nzuatoeae coss.ooa sudden-uuu.oe ensued

use>eaou «no». mesa cm: as cusses

hue-e «a gnaw Ma eon ea moosu

uena nsocemoxe :« e.uo flan neeooum

co«v«vu¢ Mo
neeooun :« cam Len eefineaueb Hoseameu use vague-0v eaevfl:

one do cassava: ofiseozom

veazvenoe en :eo «soduduve
ego. ea eee ou evsueueecoo guacaweu use u«ueelou xoe£u

aeufi menu uo eke: uueaem

nave. scion
uo eaeoouo owed n.09z hameocemouo ensvezun ou ocayzom

sue>sou¢ use». x<so ow: o» ctzoox

one: e9 :e0
encaueuev euoa ha 00. ca meta-Luncoo vaunOGOc xoezo

codweaev uo
eneooun :« vex Lou aeHLeaue> Hosanmeu use oabneIOu conch:

one to ceases-n .Hsuonom

scosuosov to» codtossto .ge see one ecsooao. use noon

wax oadwoed. uo ceaueaeu eabannOQ sou ecausem

ceaueaov
o~o«..0a to. ..uax coasaflo.-ca oapseefio co sass ecu-dam

ea.” more one - ouoeov on oanosoe

eeucego ean«..0d you acoumeu «oeaen o» ec«apee o» xoen oo

co«eeueuwe:00 some ceameh euecalddu

caucuahu :u 1.0: can scum... Lou 99— «non

 

 

 

 

 

 

 

 

 

 

 

than

 

 

.
”Awe

seepeoue an... mesa oex o» sheen.
Bhdulh L5H LGOOOEIOU

veaovenoe en
coo ecoauuuue eeea u" ee. 0» evcaeuaecoo vacuoles xoenu

coaauuee «0
eneoouauc« wax new eenbeaueb Hoseaweu use ode-elem eeevna

on: we coauavfie euspeaom

Fecaaavvd so» eaueaaho ega auu 09x veep 05v 0009

cassava. asp...oa to. ..oa¢ .spseneo co anda ous-nun
cosmos as one . we: as «unease

nososec sapsmuoa on as or. ..uax cosssfio.-:« be con
cecasexo en 0» acumen :« e.un "danceuoa he ueaa vH«=m

ualda Leaoa he
head: so»; :o«ue«>eu 005H0nne veeueeum can! coameu oveaem

«seamen u: «and eeeooum

newcego

e~bannoe Lou gnaw ca use one: ureameu hrs Ca 00- co xoe£u
mco«weu sawuraonaca Fae zucchna n00;

udlwfl HOLM COaudd>°U OaJHOQDI

mafia mxm vacuoauo .eooassoflnu as. gas: unis oo acumen ne<

scone-Hoe
to coioswnc toss“. to. "sense anemone lzm fiancee.» .H

o:«u:ou eweooH Lee mxm fiecowweu vouueane one eueasoaeo

one: eb ceu nemrenu cam Ca eon ou mesa-Luncoo aeco«weu xoenu

newceno eabaunOA Lou “evacumeu uoewee ou e:«u=o¢

.sn.n venue co vooofiou on o» .« use us on. as xoono

nan-o uefl«u e :0 venue on 0» eke n.0Qx u" 00: 0d 300:9

Leaking sand econ on See utenueaeu
Lo ecofiu«nve yam Cu eea 0a eucweevecoo eaveeloc xvezb

ICEA oTHQV

n: 1.261 .51 01.237: 0.. 2¢u3°z

.«u

 

 

 

 

 

 

 

 

 

 

 

 

197

Examining the routine in detail, Activity Block 1
checked the domestic constraints to see if any changes
in the DC configuration could take place. By setting the
data base variable NATCON off, no DC system change was
allowed and the whole routine was skipped. If NATCON
was "on," then the various in-solution and in-process
values and constraints were checked to see if changes
could take place. The total PD system variables that
were checked were MAXDCS, NMINPS and NUMDCS. The checked
in-process variables were INVSTS and MXINVS, INVSPS and
MXIVPS, NMINPS, NMBDLS and MXIPAS and NDCADD and NDCIN.
These variables were checked in a basic FORTRAN subpro-
gram and, if any of the constraints were not satisfied,
then LOCATE was skipped.

If DC changes were allowed domestically, then the
next two activity blocks checked data base variable
IUDF(l) to see if any exogenous DC changes had been
specified. If IUDF(l) was positive, then the DC‘s
packed in IUDF(l) were to be set into process that
quarter as long as the constraints for addition were not
violated. If IUDF(1) was negative, then the absolute
value of IUDF(l) was the DC to be set in the process of
deletion. This method of deletion only allowed one
possible DC to be deleted per quarter. Both of these
activities were associated with what was determined as
the addition or deletion of DC's on a fixed basis instead

of letting the basic algorithm add or delete DC's on a

198

so-called free basis. Also in any one quarter only
exogenous or endogenous changes were allowed and not

both.

 

If no exogenous changes were desired, then LOCATE
began the series of steps to determine if DC's were to
be added or deleted on an endogenous or free basis. F

Activity Blocks 4 through 11 are the activities
used to determine which of the market regions was in
the most critical need of change. Block 4 checked the
regional constraints on DC changes to see if anything
could be done in this region. Here again the basic
FORTRAN subprogram that checked the domestic constraints
was called to check the constraints for the region being
processed, IREGNO. Data base variables REGCON, REG(l),
REG(9) and REG(l7), REG(Z), REG(3), REG(9) and REG(10),'
REG(6) and REG(ll), and, finally, REG(7) and REG(lZ)
were checked against each other. If any constraints were
violated, the region was skipped for consideration.

Given the region could be considered, then Activity
Block 5 calculated an expected, regional sales modifica-
tion factor (SMF) similar to that used by the DC‘s to
modify forecasted sales for the quality of service being
given to its customers. This SMF, RLCSMF, was different
from that of the DC's in that it was calculated not only
on the basis of actual service given in the last quarter
but also the service that might be given by the present

DC's in the process of being added. Data base variables

199

REG(9), REG(l7) and REG(14) were used in the formula for
calculating RLCSMF.

After calculating the region's expected SMF, it
was compared to limits that were set internal to this
routine. If RLCSMF was greater than the lower limit and
less than the upper limit, then there was no action nec-
essary in this region. If RLCSMF was less than the lower
limit, then this region would possibly be considered for
a DC addition. If RLCSMF was greater than the upper
limit, then this region would be considered for a possible
DC deletion.

Activity Block 7 added this region to the list of
regions, RLIST, to be considered plus the deviation from
the limit of which it was outside. Block 8 indicates
that all in-solution regions, NREGS, were checked. Activ-
ity Block 9 checked to see if any regions were put in the
list, RLIST. If no regions were put in the list, LOCATE
returned back to the M&C QUAR event activity.

Given there were region(s) in the list, then Activity
Block 10 selected the region, IREGNO, with the greatest
deviation from its respective limit. A region was now
selected for a possible DC change-. In addition, IREGNO
was set negative if a deletion or set positive if an addi—
tion was possible. Activity Blocks 5 to 10 were performed
in a basic FORTRAN subprogram that was called from LOCATE.

Activity Block 11 identifies the activities asso-

ciated with building a new list, RLIST, of all the potential

200

DC's for the region to be examined in detail. Data base
variables DCP(8), IDCNOl and the total number of potential
DC's were checked to see if they should be added to the
region's list.

Activity Block 12 then checked IREGNO to see if it
was positive or negative. If negative, LOCATE went to a
subprogram that contained EXTENDED FORTRAN instructions
to see if a DC could be deleted. If IREGNO was positive,
then LOCATE went to a subprogram that also contained
EXTENDED FORTRAN instructions to see if a DC could be
added.

Given that IREGNO was positive, then Activity Blocks
13 through 16 are concerned with the possible addition of
a DC. Activity Block 13 looped through the list of poten-
tial DC's, RLIST, eliminating first the DC's that were
already in solution, were in solution and later deleted,
or were in the process of addition. Data base variable
DCP(lZ) was checked in this first step. The second step
accumulated the exponentially averaged sales dollars,
DU(9), for the DU's with which each of the eligible or
remaining DC's best served. Data base variables NDUS,
IDUNO and DCASGN were used in this process. After all
the DU's had been processed, the DC with the lowest accu-
mulation of sales dollars, DCSUM, was eliminated from the
eligible list. This elimination continued until two DC's
were left. Then the DC with the higher sales was selected

as a possible candidate for addition.

201

Activity Block 14 checked the accumulated sales,
DCSUM, for the possible candidate to see if it was greater
than the capacity constraints for the smallest size DC,
DCCAPC. If it was greater, then Activity Block 15
scheduled the DC into the process of addition. Data base
variable DCP(lZ) was set for the new in-process DC using
variables TNOW and TMINPR.

Activity Block 16 updated the various DC in-process
variables, NMINPS and REG(9) and INVSPS and REG(12) using
data base variables INVEST, DCSUM, DCCAPC, IDCNOl and
IREGNO. These last two activity blocks were performed in
a FORTRAN subprogram called from LOCATE.

After the DC had been scheduled into process and
the necessary variables updated, then Activity Block 17
represents the activities of again checking the national
constraints, checked in Activity Block 1, to see if more
DC's could be added. If so, the whole process, Activity
Blocks 4 through 16, was repeated. If not, then LOCATE
returned back to the M&C QUAR activity.

Block 19 is associated with the activity of elimir
nating a region from consideration. If after checking
all of its eligible DC's and none of them were large
enough in potential sales volume, then it was eliminated.
REGCON was set off for this region.

Activity Blocks 20 to 25 are associated with those
activities of possibly scheduling into process the dele-

tion of a DC. These blocks were a series of FORTRAN

202

subprograms that were used for both the endogenous and
exogenous possible deletions of DC's.

Activity Block 20 is strictly associated with the
possible endogenous deletion of a DC. This block used
data base variables IDCNOl, IREGNO, DCP(8) and RLIST to
determine the eligible DC's that could possibly be
deleted. In building the eligible list only RDC's pre-
sently in solution and not being deleted were considered.

After a preliminary list of eligible DC's was built,
their last quarter's cost per pound of sales was calcu-
lated. Data base variables IDCNO, DCIS(6) and DCIS(17) were
used to calculate this cost measure which was stored in
RLIST. The DC with the highest cost measure was then
selected for possible deletion.

Activity Block 21 then checked DCP(12) to see if
the DC had been in solution for at least two years.’ If
not, then this region was eliminated from consideration.
If the DC had been in solution long enough, then Activity
Block 22 set data base variable DCP(lZ) equal to the
negative sum of data base variables TNOW plus TMINPR.

Activity Block 23 called a basic FORTRAN subprogram
that updated the necessary in-process DC variables NMBDLS
and REG(lO) using IREGNO. After that activity, the data
base variables discussed in relation to Activity Block 1
were checked to see if more deletions could be made
domestically. If so, return to LOCATE Activity Blocks 4

to 16. Otherwise, LOCATE returned to the M&C QUAR activity.

 

203

Activity Blocks 21 through 24 are also used for the
exogenous or fixed deletion of a DC. If the process were
on a fixed basis, RLIST contained the DC specified in
IUDF(1). Also the constraints were set so that only one
DC could be scheduled for deletion.

'Activity Blocks 26 through 30 are associated with
the exogenous scheduling of DC's into the process of being
added to the PD system.

Activity Block 26 set data base variable IDCNOl
equal to the next DC to be unpacked from IUDF(1). The
procedure was such that up to ten DC's could possibly be
added in any one quarter. Therefore, the DC's were drawn
from this possible list of ten DC's and added into process
as long as the domestic and regional constraints were not
violated.

Activity Block 27 checked the constraint variables
NATCON, NDCIN and NDCADD to see if they were satisfied.
If not, the subprogram branched to Activity Block 30.
Otherwise, Activity Blocks 28 and 29 scheduled the DC
into process and updated the necessary in-process vari—
ables. Data base variable DCP(12) was set with TNOW plus
TMINPR to schedule the DC into process. NMINPS, INVSPS,
REG(9), REG(12) and NDCIN were updated for the new
in-process DC.

Finally, Activity Block 30 checked to see if the
exogenous list in IUDF(l) was empty. If it was empty,

LOCATE returned to the M&C QUAR activity. If not, the

 

204

next DC was selected from the list for possible addition
in Activity Blocks 28 and 29.

The last subprogram associated with the CONTROLLER'S
REVIEW section is called EXPAND. This FORTRAN subprogram
basically checked all in-solution DC's to see if they
were in need of expansion. If they were, then they were
put into the process of expansion to the next size DC.
Figure 71 shows this subprogram's data base variables.

Activity Block 1 of Figure 72 checked data base
variables NATCON, INVSTS and MXINVS, INVSPS and MXIVPS,
NMINPS, NMBDLS and MXIPAS and NMINPS, NUMDCS and MAXDCS
to see if any expansions could take place. If not, then
the activities in EXPAND were skipped.

Given that the domestic constraints were not Vic?
lated, then Activity Block 2 checked the regional con-
straints for the region being processed, IREGNO. Data
base variables REGCON, REG(ll) and REG(6), REG(12) and
REG(7), and REG(2) and REG(9) were checked.

If expansions could take place in this region, then
all in-solution DC's, NUMDCS, were first checked to see
if they were in the region being processed and then to
see if they needed to be expanded. Activity Block 3
checked data base variables DCP(8) for the correct region
and DCP(12) to see if it was not already in the process
of being expanded. If either of these conditions were
unsatisfied, then the DC, data base variable IDCNOl, was

eliminated from further processing.

 

205

outage: ecefisuogom nee-aaeua ea.-.~e cheese
seepauo- as... mesa ea: o» :us».¢
ensues you ueaeeeseu

reset
on see need-:eeue ones he eee e» needeuaeeeo odd-elem meemu

mean-«he» neeoeeenca on Hece«uee use ode-omen es» eaevo:

coneceeue e.oo on» eaapezom

oeaau u.out-a no“: on seesaw

..oa co sass ...ootl

need-ceeke eapaneed uo uadu ca use eues a.oo use ha eee ea xoesu

aceawea ceuaaaeeucd Ade nmsehnu doom

..oo cososao.-c« Ha. sweats» aces

eceaeceeue ean«eaee ue unna on on one .0. an

~aaeaa
neauaoeoe emu cena ueaeeuw eaves haaoeeeo ea eeaee on» uH

eueo haueuuezv m:«e= euueu auauedeo oh nefiee euewsoaeu

neusenue en 0»
beneaae aw .veeeeooue wcaen seawee :« .ua ha ea» 00 xeegu

acumen :« on neee eeeoOLL

venue n.0q ecsteevheaa ease ecev ea :eo
Anvceaesedxe on u« eee ea eucaeudeceo Heceaueu xoezu

ceasezo enpueeee you ceduee soee eeeoehm

ueanesu nun» econ on see
Aeveeaeneaue on «a eee ea eueaeuueceo oaoeeaev xoegu

e:e«e:eaue ua edpdeeea exem ea eeausox

 

 

zeaxm A

waboumom eeapewuqu wcsflsvonon sea-cednu haauaoem teuo.«b essenm

acosune>cn eneeeuelea deceumex
meuuun.on one eeeoeunlsd we .02
e.on ameooedu:« we .e: oaaeeaoo
unseene>cd uueoeunvcd ouueeaoo
emcene edhu + emseno on ue ends

«ea-e seamen heme nae exm

nonneooee undep seamen go .0:
nonneooua ace-n on fleece-sol
commenced wcaen on ceausaeeucu

coined: enhanced ecu fun ue «a:
cause mdaoeoeo ea eeaee on

Census. ca ..en Iguana:

ace-sodeee one + enba on

onus . ea“. on be u..:« up<

on unease o» one» heaoa

one“ veeeasna. co sue am<u
eceaueu se«u=~ee1:« he .0:

e.uo seaaeaeenca ue .en

hueoeeee eeae ueHHeo on

eeHee ueaaev ago on

Leveeaucn eeue meaneo un
eeausaoeasa on Heauseaen

easene ooh» + euseso on he slab
e.uo one eeeoeud1ca no .e: we:
ueunnn.uo one eeeoeudlsu we .ez
use-dee>:« one on eeeoeunnca men we:
aselaee>:« on coausaonucd men we:
aseauue>cd on eoeoeeelca Heseane:
a:elane>:d on ce«u:~e.o¢« Hecoauez
e.uo eueaev neeoouAIca we .e: moo
e.oa one neeoeuduca me .e: sen
med» heelce eacueeeesou Hesewuem
ueau euonce eacueuaeceu edaeeaeo
useaueebcu on eeeooualsd lea

e.oa neeoeeelsu we .ec mop we:
ace-aeeecd on eeeoeenuca see we:
acelueebca ua eeausdee|:« new we:
aseaueebca on eeuasdeencd euueeaen

IOHBLHCUMHD

x~uosne
Resume
maszz
mampzu
A~soauo
Aosvaoa
wannabe

 

 

soHnldmuu
Huanmxum

 

 

206

Activity Block 4 calculated a sales dollar to
capacity ratio that was later compared to a specified
percentage of the present DC maximum size in order to
determine if the DC was nearing its upper capacity
restriction. Data base variables IDCNO, DCCAPC, DCIS(8) and
DCIS(16) were used to calculate the sales to capacity
ratio, SRATIO.

This ratio, SRATIO, was compared to the specified
percentage of DCCAPC in Activity Block 5. The percentage
was built into the routine. If the DC was above its
limit, then it was added to a list, RLIST, of possible
DC's to be scheduled for expansion. Block 6 added the
DC to the list, while Activity Block 7 indicates that all
in-solution DC's were checked for possible expansion.
Block 8 indicates that all regions, NREGS, were checked
before any DC's were actually scheduled for expansion.

After examining all in-solution DC's for possible
expansion, Activity Block 9 was a check to see if any
DC's were in RLIST. If not, the rest of the activities
in EXPAND were skipped. If DC's were in RLIST, then
Activity Block 10 identifies the activities of selecting
the DC with the largest sales to capacity ratio. IDCNOl
was set equal to this DC and Activity Block 11 then
scheduled this DC into the process of expansion. Data
base variables IDCNOl, DCIS(Z), TNOW, TMINPR and a con-
stant of nine million were used to set DCP(12) for the

time of expansion. Nine million plus the time of expansion

207

was used to differentiate a DC being expanded from a DC
that was being added into or deleted from solution.

Activity Block 12 then updated the domestic and
regional in-process data base variables INVSPS, NMINPS,
REG(12), REG(9) using data base variables INVEST, DCIS(8),
DCP(8), IDCNO, IDCNOl and IREGNO. The difference
between the investments for the DC's present and
scheduled sizes was added to the in-process investment
variables.

Activity Block 13 is similar to the first activity
block of EXPAND in which the domestic constraints were
checked to see if any expansions could take place. If
more expansions were possible, then the program looped
back to build RLIST again and possibly expand another
DC. If no more expansions were allowed, then Activity
Block 14 indicates a return to the M&C QUAR event
activity.

Update.--The next set of routines are in the UPDATE
section of M&C's CONTROLLER. These routines activated
any scheduled changes to the PD system which was to be
tested over the next simulated quarter of activity.

The first subprogram centers on the activities
that were involved in putting DC's into solution. Various
in-process and in-solution DC variables were updated plus
the new DC's status variables were initialized for the
coming quarter of activity. Figure 73 shows the data
base variables that were involved in this DC update pro-

cedure while Figure 74 identifies the logical activities.

208

nodaepeou< cofiuaflom oonu on use--.ak orgasm
seepage. an... mesa ea: oa ensues

..:o fie. genous. soon

«a wca>uen heuue on couusn0muca ue sou ecu heusaoe an «em

on couuaaou-:e o» :n xcsa o» ocsasoe

couaooene Iehuoua Levanleo ue usm

can move e on
neuuafioeuca ea nexcua en 90: canoe so wruueoun:« house brand

ones ..na ca ..oo a.lecosoa as. rescue» soon

n.oo couosflo.-=« Hue negate» goes

on Hasscoooa ..=a .onos.- on coasnsoo-cs .dns u“ .o. on xoono
on codenaeeuca neee eneeeum

scene on cozssao.-cs exec: u.«~ ..=a :« on s... ..-ooua

:a nun» ephee see were e.uo earn-eeu ue aqua nexceu aeo
an noee eeeueum
unedueooH uo deduceDOQ HHe genous» moo;

sad-oasuosou u:-
hHHeceuweuonueuue ecueb ue eneoeed :« e.ua uo gonad: eosvem

no u:«loe:« you eeHneuues on :oueeaeeaca eaevds use eu«~e«u«:u

use: coausaeenound once e» um ease me:

eave-
.n as an: a“ us co. on sausages on Hades-ace soc. score

ceaaaaoe can“ on e one ea ecaasem

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ambumm
.n"
:9
.Nu
mmuzuom
an
umm
.uu
ozm
.ou
ztm
deem
1xomxm
.o
goo
.m
.5
.0
new
I: _
m.m<>
mmmucmm
uzu
on ”ULEI‘
muddfi
on
wpeaa:
.N % uuZH
H

3.302!” emceso '5? am
eceuuuoaoud heaaov neHee uooz
He>euum engaged vexoeeu UQ
ucenuee>ca nneoouduca Duane-on
acesuae>cd couuafieenna ouaeesoo
n.0Q uneoouanca uo .0: I00

n.uq co««:~0m|:d ue .oc wed
uceauno>c« unevouaosa Heccamem
acoEDue>cw couusweelcu aeceamem
vvauun.uo uncoord1c« uo .0: wed
eeucuea Uo coau9H0enCH
neubeues> on souasaenccn

n.oa :ouusaeensu uo .ez

commenced mcueb seamen uo .ez
penneuoud wadep on Heuuceuom
penaeuoea mcueb on neuuaflenoCH
veuneooLn waden an uo .oz

eeHneuue> couuzflem coca on o:mun.nn eudwum

aromas
xivmuutoo
8 USE
mam>zu
memszu
maszz
”plenum
“Niches
nisvume
Assume
Amino
xu~thoa
on Animuoo
nonxpz
musapbo

OZQQmH
«OZQQH
OZUQH
.HJBDB
COED

 

nm4m<um<> mauzmoonzm um:

elm mbe Que Heceuwem

ooh» v ouun on an u.>:« m><
ewe-co e83 + ewseso on ue elf—
ueuen uefiaov nae due on
ace-swaene oom + ooh» uo
neauueedeo eeun On

nauseous vexeeuu uo .oc Heuek
n.:o eu e.ua eaoueeeu uo unug
e.:n ue .0: Hence

one» nosefiauau uo see twee

zouuhuxonma

“assume

amuvduo
nouvmoa
”Linea
UL<UUQ
mWZHH
zomduo
mam:

mu): H

@242

 

 

onubAOm
thH

ubm

 

 

209

Activity Block 1 checked data base variables
DCP(12) with TNOW for each potential DC, IDCNOl, to see
if it was to come into solution for the coming quarter.

If it was to come into solution, then Activity Block 2
updated data base variables NUMDCS, REG(17), INVSTS,
REG(11) using data base variables DCP(8), IDCNOl, IREGNO,
DCIS(8), IDCNO, DCCAPC, INVEST and DCP(lO). Block 2
also initialized data base variables DCIS(l) through
DCIS(21). Specifically, DCIS(4) was set equal to the
exponentially averaged regional sales modification factor,
REG(14). DCIS(Z) was set equal to IDCNOl, the row of the
potential DC array, DCP. DCIS(8) was set equal to the
DC's expected size, while the rest of the DCIS variables
were set to zero. Also initialized were data base vari-
ables OCTDIS(1), set equal to one, and PRDC(2), which
was set equal to a negative one. Because PRDC(2) was

so initialized, the INVMGT routine would then calculate
the DC's initial inventory control variables. Data base
variable PDSCHG was also set so that additional DC to

DU information could be generated.

Activity Block 3 then reduced the necessary in-process
variables for the domestic and regional areas of considera-
tion. Data base variables NMINPS, INVSPS, REG(12) and
REG(9) were reduced. Block 4 indicates that each of the
potential DC's, a maximum of thirty-five, were processed.

The remaining activity blocks are designed to link

the DU's to the best in-solution DC that could serve it.

I
L.
1

210

The basis for picking the best DC was the heuristically
selected list of potential DC's, DCASGN, that could serve
each of the DU's.

Activity Block 5 obtained the ranked list of feasible
DC's that could serve the DU being processed, IDUNOl. Each
of the DC's in the DU's list, starting at the best and going
to the worst DC, was checked against the list of in-solution
DC's until a match occurred. This checking was done in
Activity Block 6. The matched DC, IDCNO, was then given
this DU for servicing. Activity Block 11 set data base
variable DU(8) with IDCNO which established the row of
the in-solution DC array, DCIS, to which this DU was
linked. Earlier it was noted that DCIS(Z) contained the
row of the potential DC array, DCP, to which the row of
the in-solution DC array, DCIS, was linked. Activity
Blocks 7 and 8 indicate that all in-solution DC's, NUMDCS,
were checked against the DC's in the DU's list until a
match occurred. Block 9 was an error condition in which
no in-solution DC matched the DU's list. The last DC in
the list was always supposed to be a PDC which could
never be deleted from solution.

Activity Block 12 indicates that each DU was linked
to its best DC and then the routine returned to the M&C
QUAR event activity.

The next major component of UPDATE is the deletion
of DC's from the PD system configuration. The LREPS

data base variables used in this FORTRAN subprogram are

 

211

listed in Figure 75. The subprogram's logical activities
are shown in Figure 76.

Activity Block 1 checked data base variable DCP(12)
to see if it was negative. If it was negative, then the
absolute value of DCP(12) was checked against TNOW to see
if it was time for the DC to be deleted. Data base vari-
ables, DCIS(2), IDCNO and IDCNOl were also used in this
checking procedure.

If a DC was to be deleted, then Activity Blocks 2
through 9 represent the activities that were necessary
to delete the DC.

Activity Block 2 first reduced the in-solution DC
variables NUMDCS, REG(17) and INVSTS and REG(ll) using
data base variables INVEST, DCP(8), IREGNO, DCIS(8),
IDCNO and IDCNOl. This block then set PDSCHG so that
new DC to DU link information would be generated. Activ-
ity Block 3 then reduced the in-process variables NMBDLS
and REG(lO) using IREGNO.

Activity Block 4 shifted the deleted DC's remaining
inventories-on-hand and any outstanding stockout commit-
ments, PRDC(4), back to the DC's assigned PDC. All tracked
products, ITNSP, were processed for the deleted DC, IDCNO.

In Activity Block 5, the GASP subprograms RMOVE
and FINDN were used to delete any outstanding DC to MCC
dispatched orders plus any MCC to DC dispatched shipments
for the DC being deleted. These outstanding events were

destroyed and no further processing was done with them.

212

.8338 8.; 8 338...? 2&2
Sign. as». 58 we: 3 53.x

eouoessoe answer

.69 5338...: 3. 52:5 83

euen 0a an seaweeuouca uosneuo nexueuu e>ez

epse>e esau eHbeaue> ca ence on emsenouneuen mafia octave e>ez

even eweun on soapsaoeICa obo:

sou e.oa neaeHen ea even n.0a ceau5H0ouSH uneH e>ox

neeneooau madep on convsaeeoca unea an ««ud can on xoeno

on neueHen Lou euenhoeu uuxuoa weanseueuse hue eueaeo

. =OH n.0Qm
necmdnue no“ ea Amouvncerasouhueuce>ca n.oo neuefien e>oz

codueaen Hesvoe you eeabedue> nueooudusd evanem

on uo coaueHen you newbeaue> ceausfioe1cd evenna

as on 3 8 h 8. 3 .326

one 53381: so: .186

seduoaoe menu on e eueHen ea eceusem

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

83:5; .3338 BE 8 338...? 8%:

uoueonnsw ewsego Eocene om
moanewue> uosnoud nexoeuv 0o

meaneath xcafl ooonQ

aceeueebsa oeuosaeeusd oauueaeo
n.oo eueaen eeeoeudnca ue .e: oaoueaoo
n.09 seapoaeotsa ue .e: mom

acesuueeca newvsaoeuc« Heuev mom

n.oo eueaen eneooudncu uo .o: mom
nefibeaue> on sowuzaeensH

..oo coeosaouucd uo .oz

nanneooud mcfien seamen uo .oz
nenmeooud wagon 9Q Hewuseuom
neuneueua maven on ceuusH0n1:« ue .ez

omumam
onoomm

0» auvonxm
Anvuuxua
ou Auvouxua
mem>2H
mqomzz
2.38m
Auuvomm
Aouvumm
AHNVWHUQ
ou AuVmHUQ
moaxbz

wubmubo

AuzummH
«OonH

oonH
soasou

 

mmAm<Hm<> mbozmuoazm aux

oceans» cedueaeeoca uo .ez
n.00: coaa5H0nnsd uo .ez
noosnoea nexoehu uo .ee Hevoe
09%» + eeuu on an u.>:« m><
emceno coho + emceso on ue cede
acessmaeee can + edhu no

2.3 “.3322? an as. .66

onuLHmumma

Suez
89.2
earn
52:
ANH ion
8 ES
39:.

95%:

mx<z

 

 

 

on
wumqmo

 

 

213

The next series of activity blocks has to do with
the order in which in-solution DC's were retained in the
DCIS array. The DCIS array had been designed to allow a
certain maximum number of DC's to be in solution at any
one time. If the maximum number was not in solution, then
the DC's that were in solution were put in the first rows
of the array so that the skipping of unoccupied rows would
not have to be done. Therefore, if a DC was deleted from
an inner row, then the last DC was shifted up to take the
deleted DC's row.

Activity Block 6 checked to see if it just happened
that the DC in the last occupied row, NUMDCS plus one,
was deleted. If so, then no shifting was necessary.

If the deleted DC was not in the last occupied row,
then Activity Block 7 moved the DCIS information using
data base variables IDCNO, the DC being deleted, and,
NUMDCS plus one, which identified the last occupied row.

Activity Block 8 moved the information for the
DC-MCC links to the new row plus the GASP subroutine
FINDN was used to locate the outstanding events for the
DC, NUMDCS plus one, being moved. All the events for
the moved DC were given its new in-solution DC code,
IDCNO. In Activity Block 9 the tracked product informa-
tion for the DC was moved. The tracked product informa-
tion was in data base variables PRDC(l) to PRDC(6) and
had to be moved for all tracked products, ITNSP.

Finally, Activity Block 10 indicates that all

in-solution RDC's were checked for possible deletion.

214

No PDC's were checked since they could not be deleted.

Block 11 then shows a return to the M&C QUAR event

activity.

When it came time for a

DC to be expanded to a larger

size, subprogram MODIFY performed the necessary activities

for the expansion. Figure 77
involved in the expansion and
activities. Activity Block 1
base variable DCP(12) for the
DCP(12) less nine million was

time for the expansion. Data

lists the data base variables
Figure 78 shows the logical
of Figure 78 checked data
possible expansion. If

equal to TNOW, then it was

base variables IDCNO,

DCIS(Z) and IDCNOl were also used in this checking process.

If the DC was to be expanded, then Activity Block 2

incremented DCIS(8), the DC size indicator, by one.

Activity Block 3 reduced the in-process variables NMINPS,

INVSPS, REG(9) and REG(12).
DCP(8), IDCNOl,

tion process.

Data base variables INVEST,
IDCNO, DCIS(8) were used in this reduc-

As in the subprogram that scheduled the

DC expansion,only the difference between the investment

figures for the old and new DC sizes was used as the

in-process investment.

This difference was then added to the in—solution

variables INVSTS and REG(ll) in Activity Block 4.

Activ-

ity Block 5 indicates that all in-solution DC's were

checked for possible expansion.

After checking all DC's,

the routine returned to the M&C QUAR event activity.

2:135

cadence oxen on ucnaxuu1.oe ensues

seepage. one». mesa ea: c» case-e

..oa noeeeaonnne He. genous» neon

easeseeebsa ceausaeeuca causesen use Hecoumeu ovens:

meaneduep eneoouousd oapeeflen nee He20wmeu evenem

one an uoveoansu nude on pceseuocH

eoucaaxo on on on u“ so. on goose

on coausaonlca noee meeoouu

n.oo coausaoensd ue one» undone o» osdpsem

. E
o

.9

 

>zH
qomle
Muzak:

 

_

 

m.ms>
oommIZH
museum

 

_

 

 

  

mNHm on
EEmUZH

I'I'Il

 

  

e.uo nne eeeoeuelca ue .0: we:
use-ceased on eeeoounlod Heeeduoz
ace-unopne on soeosaoo-ae decodes:
useauee>:« on eeeooenrea eaves-ea
useaveepsd on :owvsaeenca oaueesoo
e.oa nne neeoeudued ue .e: eaveeaen
eeueounsd one» ueHHen on

neueeoouo waden seamen uo .ez
noon-cote ocean on Hussnoaom
neeneooud.wsnen on soavsaeeusH

.oanqeuu> sodona.o on coduaflomucH e:¢au«...ee gunmen

Amiga:
“unease
“sauces

mmmszH

mem>zH

mmszz

Amvaoo
means

mmqdeMds maozmooozm Hma

n.0Q cowu.Hom1c« uo .oz

ooh» + oxen on an w.>c« m><
emceno coho + eMCano 0Q uo ease
acescwdmme cam + ooh» on

one» nouaawasn uo sue am<o

zOHuLHmomma

momma:
ameszH
“Navaoo
Ameaoo
3029
«Sen

mx<z

 

 

 

 

nz<mnm

 

 

 

 

216

The last subprogram in the UPDATE section of the
M&C's CONTROLLER is concerned with the development of
DC to DU link information needed for operating purposes.
Figure 79 lists the data base variables used in this
routine while Figure 80 shows the logical activities
needed to generate the required information.

Activity Block 1 checked data base variable PDSCHG
for any PD system changes. If there had been changes,
then Activity Block 2 used a basic FORTRAN subprogram to
sort the DU's in-solution DC assignments, DU(8), into
ascending order. All DU's, NDUS, were sorted with the
original row for the DC's DU's stored in DU(6). The
result of this sorting process was that all DU's for
each in-solution DC were now grouped together. The rea-
son for sorting the DU's on their DC assignment was to
develOp the basis for the Monte Carlo selection of a
DC's DU's in the D&E sales processing routine.

After grouping the DU's by DC, Activity Block 5
initialized data base variables WIACC, DCIS(3) and
DCIS(S) for the first in-solution DC, IDCNO. Data base
variables DU(8) and IDCNO were then checked for a change
of DC in Activity Block 4. If there was a change, then
data base variables WIACC, DCIS(3) and DCIS(S) were again
set to zero for the new DC to be processed.

Activity Block 6 accumulated the cumulative weighted
index by DU, DC and region using exogenous data base

variable DU(4) which was changed annually. The accumulation,

El

217

saves-sec sedan-.33 1.3 8 3 8'60 0.3:.-

kiefineltgouexoag

0.883;

eeemeeeun _le .93» 3E: ue 53590.70 e013 3 go

838e8e3§318§e§§33e3ésd

.33...» 8.3-8 .18. 3 8.3.8 8 is... been... 2.:
giSE-Shtaiaoioeg

8 3 8 use“... :8?- 8: e E
.93.. 8E8 e .835. 18 838?. £56 I» E «H

3552303330

3:. no.5 .8232. «lot: e5 8 .8 SAGA-u

83:53 .81: 3.3... 3888

on see Lou
533503 ”Sandi—see you 3.33.3) 933.35 .8 ue 09.16

neeeeeekoauseeebnEueBaHHeuaeeeQumeemu

so :03 eeeeeeu

even 8 n so owed—.5000 0» nee: eeaneaheb eeuadduch

on: 818 332% 3 $33.. ea .55ou

833e8§381l§98§m

note—59503
Bugggfieeggheegaieuxoenu

£31.83 in 8 3 8 3i.- 3 3.35.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

.2
Eu _— auoei 532:85 .23 an 3 81.4.... 2.82
IO .
v.22 x85 32$... 33.1.!» 1:338. A38:
2mm .83.: 82m?- 8 ea In 33.8:
n .53 on see 33 ue .0: A338
.0 36 .7er .5: 8.3.3 e8: :33
» 8 22-23 8.: 8.3.2. You 238
60 mm boarded on cognac-16H 8V3
. now: .8232. 3332.8 2.39
a on... 8 v3.3.» 3:8
:35»: we: 00E- 8 A38
mubmubo
non-893 ~53 8 5333-5 0.83

noneeeoud wcgn 8 3.5000.—

.825 8232. woo-H.384

3: g.» ended“. #35 and
ans-.3:- 02 + 0&5 on
:9 o C. ease'He
Lou chooeedg pee ”.1: 0,0,9:
3.1373001» on 73.-eve.—
euecdnuooouu on Heat—even
season on cog-50013
33.350000» 8
evesanhvoonn 8
mod-e395 sou neveeHee 8
.81: You»?! 8
38 cognac-05 ue .0:
neeeeooed 9:3 38 ue .0-
.Bueeancu 0»:er 'aehe am

 

 

 

 

 

onEHxUED

 

@353.» 38% an

 

 

 

 

218

WIACC, was stored in DU(7) for the DU being processed,
IDUNOl. The DC and regional accumulations were updated
in data base variables DCIS(S) and REG(B). Also data
base variable DCIS(3) was incremented by one for another
assigned DU.

Activity Block 7 again checked PDSCHG to see if it.
was set on. If PDSCHG was on, then Activity Block 8
calculated the road distance from the majorly assigned
DC, IDCNO, to the DU being processed. This road distance
was calculated using the same basic FORTRAN subprogram
used in the D&E "Distance Check" program. Data base
variables DU(2), DU(3), DCP(l) and DCP(Z) were used to
calculate the road distance which was stored in DU(ll).

.After calculating the road distance, the constant
or average service time elements T1 and T4 from the DC
to the DU were determined using data base variables
DCP(9), DCIS(2), IDCNOl and RING. This activity used
EXTENDED FORTRAN instructions to shift out the ring
set indicator from DCP(9). Using the ring set numbers
and the calculated road distance, the constant service
time elements were determined and packed into data base
variable DU(S).

Activity Block 9 checked to see if the majorly
assigned DC was a RDC-P. If it was a RDC-P, then Activity
Block 10 shifted the distance calculated in Block 8 from
DU(ll) to DU(lZ). Then Block 11 calculated the road dis-

tance from the RDC-P's assigned PDC to the DU being

i . ‘.-’\'-..—_ _

219

processed. Again data base variables DU(ll) and DU(S)
were set using variables DCP(8), IDCNOl, DU(2), DU(3),
DCP(l), DCP(Z), DCP(9) and RING. Only service time
element T4 from the PDC to the DU was determined since
the order was always assumed to be transmitted to the
RDC-P. Therefore, customer service time element T1 was
the same for both orders split between the PDC and the
RDC-P.

Activity Block 12 indicates that all DU's, NDUS,
were processed before the routine returned to the M&C

QUAR event activity.

Eupporting Data §ystem

The supporting data system for the M&C subsystem
includes three computer activities. The first computer
activity is the preparation of the LREPS exogenous
(EXOG) input tape. This program utilized EXTENDED
FORTRAN instructions to process the exogenous information
from all four LREPS subsystems. Except for the D&E
subsystem's Demand Unit (DU) tape, the inputs into this
program were punched cards. A small part of the punched
card information was from computer activities in the LREPS
supporting data systems. The high majority of this punched
card information was from non-computer activities.

As was briefly discussed in the OPERATING SYSTEM of
this chapter, the EXOG subprogram in the M&C MONITOR pro-
cessed a tape file of quarterly exogenous inputs that were

cataloged into segments of the LREPS common data base.

220

The card input into the tape preparation run was, therefore,
organized to contain the following information:

1) A variable designating the quarter in
which the catalog of information was to
be read in;

2) Identifying information as to which
supporting data system activity prepared
the data and in which simulation cycle it
was used;

3) The catalog's beginning reference number
within the LREPS common data base;

4) The number of additional sequential data
base variables read in after the beginning
reference number;

5) The mode of the data being read in for the
specified catalog of information--integer,
real, octal or tape binary (last mode for
DU tape);

6) The "data" cards themselves.

The exogenous card file was kept in sequence based
upon a sort key composed of the quarter number, the sup-
porting system identification number, the card type (a
control card--card type one--telling the number of
catalogs per quarter, an individual catalog card--card
type two, or a data card--card type three) and finally a
sequential card number within card type. The data cards

‘were read under common formats for each mode of data.

 

“H

221

The program converted the input data to the "EXOG"
magnetic tape in quarterly files. The exoqenous informa-
tion was also printed if the cycle number was different
from the base-run cycle number. This last statement refers
to the use of a base run--simulation cycle number one--of
exogenous data inputs that were needed in order to operate
LREPS. Simulation cycles after the base run were given
new cycle numbers and only the exogenous data that was
peculiar to that cycle was printed. The base cycle data
was, therefore, only printed for the base run.

No block diagram is given for this program since it
essentially merged a card deck of information into the DU
tape to prepare the EXOG tape. In essence the program
served two purposes. The first purpose was to prepare the
EXOG tape. The other purpose was to provide a meaningful
way for organizing the LREPS operating system data inputs
for easy reference and cycle documentation. At any time
the base run could be created by collecting and processing
the cycle one data.

The second computer activity in the M&C supporting
data system is an EXTENDED FORTRAN activity for converting
a card deck of information that was in standard binary
coded decimal form into an octal representation. The BCD
deck contained one card for each DU. The information in
each card was composed of the DU identifying code plus
the codes of all potential DC's that could feasibly serve

the DU. The potential DC codes were ranked in decreasing

lm.h-‘ -LSiVJ

222

order of priority for serving the DU. The last potential
DC code for a DU was that of a PDC since a PDC could
never be deleted from the physical distribution system
configuration.

The program converted the BCD deck to an octal
deck. The newly punched deck also contained identifying
information used in conjunction with the EXOG tape pre-
paration run. The first set of punched cards contained
packed computer words that contained the number of DC's
that could feasibly serve each of the DU's. The second
set of packed computer words contained the list of DC's
for each DU. This packed computer word deck was stored
in the LREPS data base array, DCASGN.

The last M&C computer activity will also be dis-
cussed-without a block diagram of activities. This basic
FORTRAN program converted the potential DC's latitudes
and longitudes to rectangular X and Y coordinates. These
coordinates were read into the LREPS common data base
variables DCP(l) and DCP(2) through the EXOG tape pre-
paration run. The same routines that were used in the
D&E "Distance Check" program were used in the conversion

process.

I I 0.1!“: .u‘ I".
-

CHAPTER VI--FOOTNOTES

lKiviat and Pritsker, pp. l-21.

223

a

CHAPTER VII

THE REPORT GENERATOR SYSTEM

Report Generator Inputs

The inputs into the Report Generator (RPG) system
included two basic classes of information. The first
class of information was the LREPS RPG tape output
generated directly from the operating system. The other
class of information was the supplementary or descriptive
information needed to clarify items in the managerial
reports. This supplementary information contained such
items as the city and state names of potential DC and MCC
locations plus tracked product names.

As was briefly discussed in Chapter VI, the first
class of information contained three files of information
for each quarter of simulated activity. The three files
of information were a quarterly control record, a file of
in-solution DC data plus a complete dump of the LREPS
common data base.

In addition, the RPG tape was designed to hold more
than one simulation cycle of information. This feature

enabled reports to be developed based on multi-cycle

224

.l-z-r: _“u ‘1
‘

225

analysis. However, no multi-cycle reports were prepared
on the computer. The present computer programs analyzed
the quarterly files of information for a single simula-
tion cycle.

The basic philosophy in developing the RPG tape
plus supplementary information was to provide a complete
data base of raw or low-level information with which to
analyze the simulation results. The desire was not to
rerun the Operating system to do additional output anal—
ysis but only to develop additional computer programs
that would analyze the stored results of the Operating
system. This output analysis took much less time using
separate computer programs instead of rewriting the output
section of the LREPS operating system and then rerunning
it.

The RPG system also allowed the flexibility of
develOping individual reports for different users of the
model without rewriting programs in the LREPS operating
system.

Finally, the RPG system allowed us to execute the
total LREPS system on a faster basis than if the operat-

ing system were bound or slowed up by a printer.

DC-Based Reports
The first set of RPG reports presented the results
that were summarized and accumulated for each DC that was
in solution during a simulation cycle. The reports were

prepared in a book form.

The philosophy in developing these reports was to

226

 

provide the basis for later report sophistication plus

present the information going from highly summarized,

aggregative data to detailed data concerning each DC that

was ever in solution in a simulation cycle. The informa-

tion was also printed in such a way as not to overload the

manager with too much information on any one page.

The book of information was prepared on 8-1/2 by ll

inch paper which contained:

1)

2)

3)

A cover page containing descriptive infor—
mation about the simulator, the date it was
prepared, the simulation cycle number plus
alphabetic information describing the pur-
pose of the cycle;

A table of contents outlining the following
information in the report;

Following the table of contents, a set of
reports that very broadly summarized quar-
terly activities-~this set of reports con-
tained one page for each quarter of simulated
activity and each page included information
about the in-solution DC's sales, total dis-
tribution cost, sales less distribution cost,
average total order cycle time plus its
average cubic inventory on hand during the

quarter;

4)

5)

227

A cycle summary of quarterly information

which was accumulated as the quarterly

summaries had been printed and which pre-

sented the DC's that had ever been

in solution during the cycle plus their

total sales, distribution costs, sales

less distribution costs, their weighted

average total order cycle time based on

orders plus the simple average of their

average cubic inventory on hand;

After the cycle summary was printed, a

series of DC detail reports--these reports

contained individual, quarterly informa-

tion categorized as follows for each DC:

a)

b)

Total sales in dollars, weight, cube,
cases, lines and orders--in reference
to the LREPS data base, these vari-
ables were DCIS(16) to DCIS(21);
Total cost for DC to DU outbound
transportation, MCC to DC inbound
transportation, DC throughput, DU,

DC and MCC communications, DC fixed
facility allocation, DC inventory
carrying and handling, and all costs
in total--LREPS data base variables
used in printing the report are

DCCOST(l) to DCCOST(6) plus DCIS(6);

gm: EAL-'fl «I

 

1“

C)

d)

e)

228

Customer service time statistics

which included the mean and standard
deviation of both the normal order
cycle time and the outbound transpor-
tation time, the inventory stockout
penalty time, T3, plus the average
total order cycle time--LREPS data

base variables used in printing the
report are DCIS(9) to DCIS(lZ), DCIS(l)
and DCIS(7);

DC information to identify certain
aspects of the DC-—this information
included DCIS(3), the number of demand
units that this DC served, DCIS(4), the
sales forecast modification factor,
DCIS(S), the sum of the assigned demand
units' weighted indices, and finally,
DCIS(8), the facility size indicator;
DC information describing the condition
of the DC's product inventories over
the last quarter and which referred to
LREPS data base variables DCIS(13), the
percentage of the tracked products'

total case unit sales that were back-

x'fi‘fi‘i ”'17:; t -i

 

'l-‘x.

ordered, DCIS(l4) and DCIS(lS), the mean and
standard deviation of the stockout delay

in getting a tracked product to a

f)

9)

h)

i)

229

customer given that it stockout out,
PRDC(3), the extrapolated, average
total cubic inventory-on-hand for all
tracked products, PRCTDC(l) and
PRCTDC(2), the extrapolated, total
number of product stockouts and
single-product reorders against the

MCC;

:MArAA-‘i -.l
O

DC-MCC reorder information concerning
the number of multiple-product reorders,
DCMCC(l), and the average reorder lead
time, DCMCC(2), from the DC to each of
its supplying MCC's;

The normal order cycle time, sales
dollar proportions, OCTDIS(l),and
customer order proportions, OCTDIS(2),
for the DU's served from this DC (A
report was printed for each set of
proportions);

The accumulations, WTACUM, of the

amount of weight shipped in the various
DC weight categories, DCWB, to the DU's;
The accumulations, DCMCCl, of the amount
of weight shipped from the DCts supplying
MCC's in the various shipment weight
categories, MCCWB (A report was printed
for each supplying MCC and the defined

weight categories).

 

230

Appendix 2 gives a sample printout of the basic
report formats for the entire DC-based reports.

Given the above output, Figure 81 shows the logical
activities associated with the preparation of these dif-
ferent reports that were printed in an assembly and
EXTENDED FORTRAN program. Activity Block 1 indentifies
the initialization process of reading card information
concerning (1) the potential DC and MCC city names,

(2) the report's cover page and (3) the report's table
of contents. Activity Block 1 also read the control
record for the first quarter from the RPG tape for cycle
identification information. Block 2 then printed the
report's cover page and table of contents.

Activity Blocks 3 to 7 then describe the activities
of preparing the quarterly summary reports for all
in-solution DC's, of the building of a cyclic work file
of each DC's detailed quarterly information and of the
accumulation of the DC's summarized, cyclic data. 'Asso-
ciated with the above activities, only the quarterly
"DC" files of information in the LREPS RPG tape were
processed. The other RPG quarterly control and data base
files were skipped.

After the quarterly summary reports were completed,
Activity Block 8 represents the activities of printing
the cycle summary report. The basis for the preparation
of this report was simple arithmetic. Thus, this report
could be the focal point of the use of more sophisticated

and detailed financial and mathematical analysis.

 

 

 

 

PREPARE
DESCRIP
INFO

 

 

 

PREPARE

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

PREPARE
DC

 

 

 

 

 

PREPARE
GLOSSARY

 

 

10.

i

1“.

E

3.

231

Start processing RPG DC-based reports

Initialize variables. arrays. potential DC names, MCC names,
cycle identification inforaation

Prepare initial. descriptive inforaation about report

Process each in-solution DC per quarter

Prepare line of DC information for quarter

Put DC on work file and set indicator that DC was in-solution
for quarter

Accumulate cycle summary data

Loop through all in-solution DC's for quarter

Loop through all quarters in RPG tape file

Prepare cycle summary information

Process each in-solution DC

Check to see if DC was ever in-solution during cycle

Read DC's work file and store data for each quarter that it
was in-solution

Loop through all quarters that DC was in-solution

Propare DC detail reports

Loop through all in-solution DC's

Prepare glossary of mnemonics and their interpretations

End of report generation

Figure 81‘.-RPG DC-Based Reports' Activities

232

This cycle summary report was printed after the
quarterly summaries because of the savings in computer
time processing and storage. The page, however, was
placed immediately after the table of contents and before
the more detailed quarterly summaries.

Activity Blocks 9 to 13 identify the activities of
preparing the detailed DC reports. These reports were
only prepared for DC's that had ever been in solution
during the entire simulation cycle.

Finally, Activity Block 14 represents the activity
of printing a glossary of mnemonics and their interpre-
tations that were used in preparing the report and column

headings.

LREPS Variable List

This basic FORTRAN activity was used for validating
and checking the values of LREPS data base variables at
specified quarters of simulated time. The listing or
dump of these variables included the catalog position or
reference number of the desired variable in the data
Jbase, the number of elements that were associated with
this variable plus a listing of the data.

The input into this program included:

1) A card was read which was used for computer
run identification--this card was printed
across the top of each page;

2) A deck of cards containing information for

the LREPS "cataloged" data base--the

233

information included each variable's
beginning sequential position or catalog

reference number in the data base which

 

could be subtracted from the following
variable's reference number to determine
the total number of elements associated
with the variable plus the cataloged V‘
variable's mode of data was included in
the card deck;
3) The LREPS common data base files on the
RPG tape--all other files on the RPG tape
for the cycle being checked were skipped;
4) A deck of "instruction" cards that identi-
fied the LREPS data base variables that
were to be dumped and provided a control
digit, called the "file skip control,"
which indicated whether more variables
were to be dumped from the present quar-
terly LREPS data base file (zero used to
indicate this), or indicated whether addi-
tional variables were to be dumped in the
Xth file succeeding the present file for
this cycle.
.Figure 82 shows the block diagram of activities to
dump-the LREPS data base variables. Activity Blocks 1
and 2 initialized the report heading plus the basic data

base information needed to dump the variables.h Blocks 3,

) Start processing variables to be listed
;:i:___1
PREHR81° Prepare identifying information as report heading
1J3
I30

Initialize information for catalog of data base variables

 

Process each data base file of information

frocess each instruction card

List item(s) using correct mode

 

 

I .. . . .4 - .-
r“"" CD to“? trrourn ;;l instrucgicn cares Par file

all data ba“a filss

'::‘ > End of analysis

“3 . 9% f“ ~, 3‘ _ o .r ‘ C ,n '. . '.‘ -- - ': ~\
cigars 8r,--aru Vsria-ie List h-ut-“o

 

 

235

4 and 5 dumped the data from the LREPS data base files

according to the deck of instruction cards.

CHAPTER VIII

TOTAL COMPUTER MODEL

Operating System Linkages

Figure 83 illustrates the linkages between the major
subprograms of the LREPS operating system and the model's
major subsystems. The subprograms are divided into GASP
and non-GASP routines. The non-GASP routines represent
the user-written routines that were developed by the
LREPS project team. These non-GASP routines are further
subdivided on the basis of event activity. For each
event activity, the lines below the event subprogram
block indicate the routines to which it was linked. The
linkages between the subprogram blocks flow downward, to
the right and to the left. The downward orientation
signifies that a routine or routines below a certain sub-
program block to which they are connected was called by
the upper routine during program execution.

Figure 83 also serves as an illustration of the
connection of the major subsystems in the operating system.

The two subprograms of the D&E subsystem are identified in

236

237

NON-GASP

GASP

 

EVHITS

FILEH

 

 

IEDCIC I

 

 

E
MONTH

 

 

INVMGT

300

_III III I

 

;

 

 

 

 

wig:

RNOE‘I

DATAIN

DRAND

 

 

 

Figure 83.-LREPS Operating System use...

238

the box outlined with bold dashed lines and labeled "D&E."
Below the D&E subprograms are the OPS .1bsystem routines
some of which were called on a fixed-time basis from the
D&E subprogram SLSPRC and the other two routines called
on a variable-time basis from the M&C EXECUTIVE. At the
bottom of Figure 83 the MEAS subsystem routines are
identified plus their linkages to the M&C end-of-quarter
subprogram. The remaining subprograms in Figure 83 are
associated with the major sections of the M&C subsystem.
Figure 83 does not entirely identify all linkages
among the operating system's subprograms. The linkages
between some of the user-written subprograms and the GASP
subprograms FILEM, which was called by several user-
written routines, and FINDN and RMOVE, which were called
by the M&C subprogram DELDC, have not been shown. Also
the linkages among the GASP subprograms themselves are
not illustrated. The main purpose of Figure 83 is to
identify the entire set of operating system subprograms,
the GASP and non-GASP routines, the linkages among the
user-written subprograms plus the linkages among the

LREPS D&E, OPS, MEAS and M&C subsystems.

Activating Alternative LREPS VersiOns

 

In developing a computerized operational model of
LREPS, the approach was to serially Operationalize the
entire D&E, OPS, MEAS and M&C LREPS subsystems. As
these subsystems were operationalized, they were merged

to form the alternative versions of LREPS.. After the

239

four subsystems were operationalized and merged to form
the first total LREPS computer model, new versions of
LREPS included sophisticated versions of existent sub-
programs.

In order to Operationalize a specific version or
level of LREPS, an input-output computer system flowchart
of the LREPS operating system was needed. Figure 84
shows the flow of information into and out of the LREPS
operating system. The inputs included the GASP card
deck of GASP run control cards and the exogenously set
BOCYC and EOCYC events for the GASP filing arrays NSET
and QSET. The remaining inputs were the order file and
the exogenous input magnetic tapes. The outputs of the
program included the GASP run control listings plus the
RPG magnetic tape.

Using the approach for computerizing the model plus
the input-output system flowchart illustrated in Figure
84, the objective of the first version of LREPS, LREPS-l,
was to Operationalize primarily the D&E subsystem. All
D&E subsystem supporting data and operating system pro-
gram routines were programmed. Besides the D&E program
routines, the GASP subprograms plus the user-written
routines MAIN, EVENTS, BOCYC, EOCYC, YR, HYR, QUAR, MONTH,
DAILY, SCHED, a simple PUTDCN routine to initialize the
starting DC configuration, a basic DCDU routine to link
the DU's to the starting DC's and to generate their

cumulative weighted indices, a basic EOQ routine to output

 

240

 

 

 

 

 

 

 

 

 

EXOG ORDER
GASP INPUT FILE
DATA TAPE
DECK TAPE
LREPS
OPERATING
SYSTEM
GASP
LISTING SigE

Figure 84.-LREPS Operating System Input loutput Flowchart

241

the LREPS data base, EXOG and B00, used to initialize the
DU and DC data base variables, were developed. Besides
operationalizing the D&E supporting data system programs,
the M&C supporting data system programs for preparing the
exogenous input tape plus the program that packed the
feasible DC's per DU were also programmed.

The primary reason for operationalizing LREPS-l
was to begin experimenting with alternative techniques
for processing the customer order file. As was discussed
in Chapter III, the design of the processing procedure for
the order file required considerable time and effort.
This tape file could have reduced the operating system to
an input-bound program resulting in excessively long com-
puter execution time to process a simulation cycle.
Therefore, LREPS-l was a critical step in the overall
research since solving the problem about the potentially
long input time was fundamental to the operationalization
of the mathematical model.

The output of LREPS-l was sales information at the
DC and DU stages of the physical distribution network.
Sales information was also accumulated at the regional
and domestic levels. This output was printed using the
RPG "Variables List" routine.

The purpose of the second version of LREPS, LREPS-2,
was to Operationalize the merged D&E and OPS subsystems.
The system flowchart contained in Figure 84 applied
although more inputs were now added to the EXOG input

tape.

I!"

242

The OPS subsystem computer program routines were
programmed and added to those routines already programmed
and tested in LREPS-l. At this point several of the
routines used to Operationalize LREPS-l were sophisticated.
In particular, DCDU was sophisticated to calculate road
distances plus calculate the constant customer service
times. The M&C operating system subprograms RWRC, used -
to calculate the ratio of total to tracked product weight 3
sales, and a basic INVMGT, used to calculate the inventory ‘1
control variables, were also added to the LREPS operating
system.
LREPS-2 had the capacity to process customer orders
through the DC's, generate customer service times, and
effect MCC to DC interactions as a result of customer
sales. The outputs were printed using the RPG "Variables
List" program. Besides the sales information listed for
LREPS-l, LREPS-2 outputted DC inventory information, MCC
to DC reorder information, basic customer service times
data and domestic tracked product sales information. In
addition to the OPS subsystem supporting data system pro—
gram, the M&C routine to calculate the DC X and Y rectan—
gular coordinates was operationalized.
The third version of LREPS merged the MEAS subsystem
program routines with LREPS-2. In addition, the M&C
operating system subprogram EOQ was revised to output not
only the LREPS data base but also the quarterly control

and DC files of information. The MEAS supporting data

243

system cost information was also added to the exogenous
input tape in order to determine the measures of cost
for the physical distribution system configuration that
was initialized at the beginning of cycle.

Because the DC file of information was added to the
RPG tape output, the RPG "DC-based" report program was
operationalized in LREPS-3 and used to print the DC 4“
reports. With the operationalization of LREPS-3, a given ~
or specified physical distribution system configuration
could be initialized at the beginning of cycle and simu-
lated in the LREPS operating system over the planning
horizon. The LREPS-3 computer model could not, however,
add or delete DC's or modify the sizes of DC's.

In LREPS-4, the remaining M&C subprograms were
merged with LREPS-3 to develOp the first complete version
of LREPS. LREPS-4 did not, however, include the LOCATE,
EXPAND and INVMGT routines described in Chapter VI.

Rather LREPS-4 included a basic LOCATE routine that only
allowed the addition of DC's and an INVMGT routine that
calculated inventory control variables according to the
policies being used by the industrial research supporter.
The output of this version was the same class of output
as develOped in LREPS-3. The supporting data system
inputs were expanded to include the management control
parameters and the constraints on allowable physical
distribution system changes. All RPG programs were at

this point operationalized.

244

LREPS-5 is the final version of LREPS with which
this dissertation is concerned. The substitution of the
sophisticated LOCATE routine plus the addition of the
EXPAND routine were implemented in LREPS-5. LREPS was
now capable of adding, deleting or modifying the DC
facility configuration either exogenously on a fixed

basis or endogenously on a free basis. With this more .m‘

« 41.1.1

sophisticated version of LREPS was the requirement of

setting additional constraints on the allowable changes «-

v—

to the physical distribution system configuration.

Further versions of LREPS are planned for develop-
ment. LREPS-6 will be the version in which the use of
partial-line distribution centers is completely opera-
tionalized. The basis for LREPS-7 will beta substitution
of the theoretical INVMGT routine for the presently
Operationalized routine. Additional versions of LREPS
can be developed by substituting for and adding program
modules to those presently developed.

In order to maintain and execute any version of
LREPS, all LREPS program modules were contained in a
LREPS program library tape. Using control cards, program
changes and corrections were updated to this tape. If a
certain version of LREPS was desired, then, through a set
of control cards, the correct program modules could be

linked and compiled together.

245

Preliminary Model Validation Results

The preliminary validation of the results of the
simulation model centered primarily on those activities
involved in the calibration of the model's output to a
specified base year's data. The model was initially set
to run over a four-year period. The first year was the
year with which the model was calibrated. The following 1
three years were used to check the model for steady- 1
state implications including no wild fluctuations in the -
model's output.

Table 1 lists the categories of variables that were
checked for reasonableness, the specific data base vari—
ables that were checked, an indication as to whether the
variables were within a reasonable percent of the base
year data plus the physical distribution stage for which
the information was checked. This basic validation of
the model results was static in nature. One full year's
actual results were compared to the simulated results.
No sophisticated techniques for simulation validation
were used that, for instance, analyzed the model's out—
puts for autocorrelation or for statistically significant
relationships between base year and model data. Disserta—
tions that are forthcoming will devote their attention to
an in-depth validation of the model.l It is in these
dissertations that sophisticated methods and approaches

for validating a simulation model will be investigated.

246

 

 

 

 

 

 

TABLE l.--One-Year Validation Results.
SIMULATED
INFORMATION DATA BASE VERSUS PD
CATEGORY VARIABLES ACTUAL STAGES
(hut Sales DU( 13—1‘4») Within Limits DU, DC and
DCIS(16-21) Within Limits Domestic
Oust Dollar DCIS(16)] Within Limits DC and Domestic
Sales /0rder DCIS(21)
Oust Wt Dc13(17)/ Within Limits DC and Domestic
Sales/Order DCIS(21)
Line Items DCIS(20)/ Within Limits DC and Domestic
per Order DCIS(21)
0181'. SON-f-
NOCT-Avg DCIS( 9) Within Limits DC and Domestic
NOCT-Std Dev DCIS(10) No Data Avail. DC and Domestic
Th—Avg DCIS(11) Within Limits DC and Domestic
Tit-Std Dov DCIS( 12) No Data Avail. DC and Dalestic
Dollar Props OCTDIS(l) No Data Avail. DC only
Order Props OCTDIS(2) Within Limits DC only
DC-MCC DCMCC(l) Within Limits DC only
Reorder DCMCC(2) Within Limits DC only
PRDC( 6) Within Limits DC only
PRCTDC(2) Within Limits DC only
DC St ockouts PRCTDC( 1) No Data Avail. DC only
DCIS(13-15) No Data Avail. DC only
DC Avg IOH PRDC( 3) Within Limits DC only
Oust ship WI‘ACUM Difficult to DC and Domestic
Accums Compare Because
of Small Sample
Avgs. in Oust
Order Blocks
MCC Ship DCMCCi Within Limits MCC only
Accums
Total Prod TPDEM(Z) Within Limits Domestic only
Demand
PD Cost DCCOST(1-6) Within Limits DC and Domestic
DCIS(6) Within Limits
PDTCST Within Limits
Cum Wt Indices DU( 7) Sales Allocation DU, DC
DCIS(5) Basis and Regional
Rm(8) Within Limits

CHAPTER VIII-~FOOTNOTES

Bowersox, et al., Monograph.

247

. "Amen-___. “1'

 

CHAPTER IX

RESULTS AND IMPLICATIONS

The first section of this chapter focuses on a wt
discussion of the results in relation to the research
questions presented in Chapter I. These questions
served as general guidelines and constraints on the
formulation of the computer model. The following sec-
tion of the chapter discusses implications for future
research. Initially,implications for research similar
to that conducted in this dissertation are presented.
This treatment broadly discusses the methodology used
in developing large-scale computer simulation models.
Next, more specialized, narrow areas of potential
research are identified. These potential areas of
research resulted from the develOpment of certain aspects

of the computer simulation model.

Results Concerning Research Questions

Researchguestion 1
Research question one states:

What programming languages will facilitate
the develOpment of a reliable computer model

248

249

including the supporting data system and
the report generator system?

In reference to the LREPS operating system Of the
computer model, the GASP IIA simulation package facilitated
and expedited the computerization Of this system. The
user-defined and simulation-defined concepts provided by
this language assisted in the conceptualization of the
computer model. The GASP EXECUTIVE routine alleviated
the need to design routines to direct the model through
simulated time.

In implementing the GASP IIA simulation package on
Michigan State University's CDC 6500, a small delay was
experienced because some of the subprograms required
minor modifications. Any subprogram that used the pseudo-
random number generator DRAND had to be changed to use the
pseudo-random number generator, RANF, for the CDC 6500
computer operating system. In addition, the GASP IIA
subprograms TMST, COLCT and OTPUT had not been com-
pletely modified for the floating point array, QSET.
Although these three GASP IIA subprograms were not used
in the LREPS Operating system, they were used in imple-
menting and debugging the GASP IIA simulation package
and, therefore, required modification. One other subpro—
granlhad to be modified. The GASP IIA subprogram DATAN
had to be renamed as DATAIN since the previous name was
already used by CDC as the name of the double precision,

arc tangent function. In summary, the GASP IIA simulation

 

250

package was sound even though it required a few minor
modifications.

In reference to the supporting data and report
generator systems, the use of the general compiler lan-
guage FORTRAN was generally the most apprOpriate program-

ming language. The primary exception to the use of FORTRAN

‘l

was the use Of the CDC 6500 assembly language, COMPASS, for

tape handling. The use of COMPASS for tape handling was

'11-‘27: -

necessary since FORTRAN is generally an inefficient lan-

guage where considerable tape handling is required. The
FORTRAN tape handling routines are usually slow plus their
use of magnetic tape storage space is inefficient.

In summary, the use of a simulation language, a
general compiler language and an assembly language was
necessary to computerize LREPS. The complexities of the
system model, the desire for efficiency in program execu-
tion and core memory utilization plus the use of magnetic
tapes required the use Of all three programming languages.
Whether high-level simulation languages such as GPSS or
SIMSCRIPT II could have been efficiently and effectively
used.in LREPS computerization is a possible area of more

in- depth re search .

Research Question 2
Research question two states:

What model building procedures will facilitate
the development Of the computer model, the
later SOphistication Of the model's defined
activities, the broadening of the model to
encompass additional horizontal and vertical
aspects of the total business system, and

 

251

satisfy the strong desire for universal
applicability among packaged-goods firms?

The use of building blocks as the common basis for
many of the model's activities facilitated the development
of the computer model. In particular, the basic building
blocks prOgrammed in the LREPS operating system served
four major purposes. These purposes were:

at“

l) The use Of these blocks allowed the project

M‘
1 e _ ;._ .
..

team to allocate efficiently their time among
the specific activities of the mathematical |
model.
2) The blocks facilitated the changing of the
computer program when a better approach to
the computer modeling of an activity was
developed.
3) Basic building blocks forced the examination
Of common elements of system activities.
Instead of develOping a subprogram for each
potential DC location, the general or univer-
sal aspects Of the functions Of a DC were
modeled and computerized. Thus, the same
computer subprograms could be used for the
functions of many DC's.
4) Basic building blocks saved computer memory
while execution time increased very, very
slightly because of the additional subpro-

gram linkages.

252

In general, the use of basic building block subpro-
grams facilitated the overall develOpment Of the computer
model and especially the LREPS Operating system. Changes
in a major activity of the mathematical model were easily
made by changing the subprogram associated with that
activity. Initially, the direction was to have a pro-
liferation of subprograms with its accompanying set of
program linkages' problems. However, later the subpro-
grams were redefined in respect to the major components
of the mathematical model. This redefinition partially
alleviated the problem Of many, little subprograms.

The future use of computer subprograms for model
sophistication would seem to be easily and practically
achieved. Their use for broadening the computer model's
Operating system to encompass additional horizontal and
vertical aspects of the total business system is limited
only by the remaining amount of computer memory and the
applicability of the present building blocks to the
possible activities that would be added to LREPS.

The universal implications of the present building
Ablocks for packaged-goods firms is limited by their com-
patibility with the activities defined in the model
framework Of a physical distribution system.. The overall
design Of the model would not have to be modified although
some of the model's activity subprograms may require

slight modifications.

EA“ "

 

253

Research Question 3
Research question three states:

What computer software and hardware features
will allow the structuring of the simulation
model's data base and its input/output
requirements that will minimize reprogramming
these structures for alternative LREPS versions?

With the use Of both the special hardware features
and the sophisticated software features of the CDC 6500,

the required reprogramming for alternative versions of

LREPS was minimized. The hardware features centered on

the effective use of magnetic tapes, disks and punched
cards where speed and controls were needed in programming

and debugging LREPS. The software features centered on

the definition Of the LREPS common data base plus the

effective use Of the program and information, storage and

retrieval systems, that are discussed in Chapter VIII, for

MSU's CDC 6500. Although the use of many of these storage

and retrieval systems is somewhat difficult to learn,
MSU's systems were easily learned and expedited the com-
puterization process of alternative versions of LREPS.

This was true even though the files had to be recreated

several times when they were lost because the computer

system faltered.

Research Question 4

Research question four states:

What computer software and hardware features
will promote the efficient processing Of the
great amounts of information that will accom-

pany a model Spanning a maximum ten-year
planning horizon?

r .n‘hsfl . i

254

Imsearch considering alternative methods for stor-
ing, retrieving and processing the computer model's data

base Of information resulted in the use and disuse Of
certahicpmputer hardware and software features. The

nore.hmxutant features that were investigated are dis-

cussed below.
Sequential, magnetic tape files were majorly used

 

fer the inflow and outflow of information manipulated in

the LREPS operating system. Initial tests using random-

access, disk files for banks Of information related to
the order file showed this method Of information processing
to be much slower and more expensive than the tape-handling

procedure that was developed. The remaining information

in the data base that could effectively be random-accessed

was so small that this information was kept in high-access,

core memory. The use Of low-access, extended core stor-

age (ECS) for this information was not possible since ECS

was unavailable on MSU's CDC 6500.
Tflue periodic input and output of information into

the LREPS Operating system via the M&C gatekeeper proved
Magnetic tape was also

to be efficient and effective.
The only

used as the medium for this input and output.

exception was the limited use of punched cards and printer
listings.
TTue use of computer program overlays for those

portions of the LREPS operating system that were only

referenced quarterly or less frequently was also investigated.

255

Program overlays were not used because the present
overlay procedure for FORTRAN programs on the CDC 6500
is not easily implemented and quite complicated.

The procedure Of packing more than one piece Of
inflnmmtion in a computer word of memory was used. Much

of the information in the model was based upon a zero-one,

binary representation. Where a certain category of infor- r-

 

mation was based upon this representation plus there was

a considerable amount of information involved, packing

*‘K "’2". .

was used.

Research Question 5
Research question five states:

What is the most efficient way to write the
model's output in order to provide reports
of the essential data and to provide storage
that can be easily accessed later as input
to programs for further simulation results'

analysis?
The periodic output of simulation results via
lnagnetic tape has proved to be very efficient and effec-

tive. The reports described in Chapter VII were easily

prepared plus the basic simulation data is available for

further analysis. Also by establishing the DAILY and

MONTH fixed-time events in the LREPS Operating system,
the use of these routines to print any additional data

was easily effected. In summary, the periodic orientation

to model results has been satisfactory.

256

Research Question 6
Research question six states:

Can a LREPS model be developed that will
by highly compatible among different
computer manufacturing systems?

LREPS is presently machine dependent and has low

compatibility among other computer Operating systems.

m _“flfil‘ Jl

Low compatibility among computer Operating systems is
stressed because it would be fairly difficult to imple-
ment the present computer model on even another CDC 6500.
Large computer operating systems for machines such as the
CDC 6500 generally have peculiarities that have been

developed by university personnel and which cause conver-

sion problems.
Considering other computer manufacturers' Operating

systems, LREPS' implementation would be very difficult on

their systems. Because more than one piece of information

was packed into many computer words, the availability Of

EXTENDED FORTRAN routines to unpack the information would

be required. Associated with the packing of information

are the differences in the physical sizes Of the computer

memory words among different computers. The CDC 6500 has

sixty bits per word while the IBM 360 series has thirty-

two bits per word. Since some of the LREPS data base

variables have more than thirty-two bits of information
packed into one computer word, then the LREPS data base

would have to be redesigned for two words Of IBM memory.

257

 

The level Of the FORTRAN compiler itself would

prohibit some computer Operating systems from being used

for LREPS. MSU's FORTRAN compiler is an advanced version

that includes such features as "logical" storage and

instructions, tape buffering routines, plus NAMELIST and

variable formatting procedures. The use Of such features

requires a large, sophisticated FORTRAN compiler.

7“.

Research Question 7
l

Research question seven states:

Can a model be developed that will run on
medium-size computer Operating systems?

The results concerning research question seven are
closely related to the results Of research question six.

The present design Of the LREPS computer model requires

a large-scale system such as the CDC systems available

at Michigan State University. LREPS requires a large-

scale computer system for fast compilation and execution.

LREPS also requires a machine with large amounts of high-

access computer memory. TO retain the universal aspects

of LREPS, a sophisticated computer operating system that

allows one to retrieve and compile quickly the LREPS

program routines is also needed.
With these requirements on the size and speed of

the computer Operating system, a medium-size system

would generally not be capable of processing effectively

and efficiently the LREPS simulator.

258

Research gestion 8
Research question eight States:

Can a computer program of the main Operating
system Of LREPS be developed that will:

a) Cycle through a ten-year planning horizon

within a total elapsed computer time of
30 minutes?

b) Fit within a computer memory limitation
Of 36K decimal words?

Require no more than three input and out-
put files?

“. \_
I

C)

 

In reference tO the computer memory utilized in the
execution of the LREPS Operating system, the most sophis-
ticated version presently requires a little less than
thirty-two thousand decimal, computer words Of memory.
Without primarily the capability Of packed computer words,
the restriction of fitting the LREPS Operating system
within 36K decimal words Of computer memory would never
have been satisfied.

In order to restrict the amount of information that
was inputted and outputted from the LREPS Operating system,
it was desired that the developed computer program Of the

LREPS Operating system require the usage Of only three

input/output files. The restricted use Of only three

input/output files would promote the efficient use Of
computer Operating systems plus allow the possibility of .
converting LREPS easily to other computer Operating systems.
However, Figure 84 illustrates the use of five input/output
(Iriginally, it was planned that no cards be read

files.
from the card reader or no output be printed during program

259

The fact that

 

execution of the LREPS Operating system.

GASP required card input and outputted control listings

on the printer was overlooked. However, considering the

small amount Of card input and printed output by the GASP

subprograms, the desire for the use of only three input/

output files should be considered satisfied.

The first part of research question eight is con-

cerned with the execution time Of the LREPS Operating

wet—W1
i.

system. In order to minimize the cost of executing the

LREPS Operating system, the desire was tO develop a com-

puter program that would process a ten-year cycle of

information in thirty minutes. This execution time is

in reference to both computer central processing and peri-

pheral processing time since they are presently about

equal. Examining the computer times of several test runs,
the length of time for running a ten-year cycle was pri-

marily a function Of two factors.
The first factor was the total sales dollar forecast

for the market regions being processed. If all the

regions were being processed, then it was the domestic

total sales dollar forecast. The running time had a high,

direct correlation to this factor when considering the

method for processing customer sales from
With the buffering Of the order file into

the order file.
the LREPS operating system, the central processing time Of

program execution was just slightly greater than the peri-

pheral processing time associated with input and output.

260

Given a larger or smaller sales forecast, then the model

took respectively more or less time to process the sales.

The second major factor affecting execution time
was the average sales dollar amount per customer order.

This factor had an inverse relationship to the amount Of

time that it took to execute a simulation cycle. If the
If]:

average dollar amount per customer order was large, then
the sales dollar quotas per day were filled much faster

which caused the Operating system to execute faster.

Other factors were considered in the investigation. One

of the more important factors was the number Of tracked

products. After running the program with twelve tracked
products and then fifty tracked products, there was no

appreciable difference in running time. Most Of the

tracked product processing was done while the order file

was being buffered in.
In order to obtain some idea as to how fast the

program would run given various levels Of the two major

factors, the execution times of several. LREPS tests were

analyzed in detail to derive a formula that could be used

to approximate the running time Of the LREPS Operating

system. The formula which gives the computer time in

minutes of computer central processing unit (CPU) time

is :
NYRS
45°TDSF.
T = Z ___.2:
ADPCOi

i=1

261

where:
T is the total amount Of CPU time per
simulation cycle:
NYRS is the total number Of simulated
years tO be run,
TDSFi is the total sales dollar forecast
(in millions Of dollars) for the ith year 31‘

and the market region(s) under analysis,

 

and ADPCOi is the average sales dollars per |
customer order in year i.
As an example Of the use Of this formula, if the annual
sales forecast were one hundred million dollars and the
average sales dollars per customer order were five hun-
dred dollars, the expected running time for that year Of
the cycle would be nine minutes. If there were ten years
that had about the same sales forecast and average dollars
per customer order, then the simulation cycle would have
taken approximately ninety minutes. This is much greater
than the desired thirty minutes. However, with that same
forecast for all ten years plus the same average dollars
per order, approximately two million customer orders
would have been processed. For that amount of customer
order processing, the time does not seem unreasonable.
Ii sixnilar example requiring a total computer run
:ime through a ten-year cycle of thirty minutes or less
ould have been constructed. However, when considering

1e consumer-oriented firms who might be using such a

 

262

model as LREPS, the computer run times per cycle seem

unreasonable. This is especially true if firms with
large sales forecasts and fairly small customer orders

were to use the LREPS operating system.

Implications for Future Research
This section of the chapter is subdivided into two

major sections. The first section focuses on a discussion

of critical aspects in the design, implementation and
The

testing of large-scale computer simulation models.

identification Of these critical aspects will hopefully

assist others in the develOpment Of the approach to and
The second

the actual implementation Of computer models.
The

section discusses future potential areas Of research.
identified areas of possible research resulted from the
implementation of various computer modeling concepts plus
computer lindtations and inefficiencies that exist in

relation to the presently Operationalized computer model.

Critical Aspects in Computer Modeling

In computerizing the LREPS mathematical model,
several aspects of this process, subject to the constraints

outlined in Figure 4 of Chapter I, were critical. In order

to assist others who may formulate similar computer models,
these critical aspects are discussed in a step-wise pro-

cedure that system analysts should perform.
After completing the feasibility study and early in

the formulation Of the specifications of the mathematical

 

263

model, the selection of the predominant computer program-

ming language should begin. The modeling concepts that

are Offered by the available simulation languages aid
in the determination Of the type Of simulation model to

be designed plus aid in determining the information

requirements of the model. In addition, if a simulation

language, rather than a general purpose programming lan-

guage, is considered as the predominant language, then
the develOpment Of simulation timing routines will not

require the attention of the system analysts.

In defining the type Of simulation model and its
related information requirements, those areas Of the
system model which could require the handling of large
amounts of information should be identified. The type
and amount of information can be a major factor in the
decision as to which simulation language will be used.
The design Of computer procedures for processing the
potentially large files of information should begin even
‘before the final selection of the predominant computer
language» In LREPS, the customer order file is an
example of one of these areas Of the model that required
the processing of large amounts Of information. The pro-
cessing of customer information could have required con-
siderably more time in both the supporting data and the
Operating systems of LREPS than is presently required.

Associated with the customer order file was the processing

of tracked products for inventory control and management

‘11

ii?“ 3_ 7“.

 

 

.i

264

 

purposes. The information requirements Of a tracked pro-

duct necessitate large amounts Of computer memory plus

peripheral storage capacity. The procedure for handling

and extrapolating the tracked product information required

considerable time to design.

The approach in reference to the above areas should be
r

to design and test various alternative computer procedures

as quickly as possible. Testing should take place even

though major revisions in the procedures may take place {—

many times. The investigated procedures should include,

for example, the use of tape and random-access peripheral
equipment, packed information in computer words and

sampling approaches to estimation.

The result of these activities should be the develop-

ment of efficient procedures for processing the large

files Of information. The procedures should be efficient

from the perspectives of both computer memory and execu-

tion time.
As computer procedures are investigated and designed

for model areas requiring the handling Of large amounts of

information, the type of the simulation model should be

explicitly defined. The simulation model can be defined

as either a fixed-time Of variable-time model, continuous
or discrete, dynamic or static and whatever other classi-

fications are necessary. The type of system model limits

the applicable simulation or programming languages and,

therefore, should then be determined at this point in the

formulation Of the computer model.

265

To further substantiate the defined type of system

model, the next critical aspect of designing the computer

model should be a preliminary Specification and estima-
tion of the size of the model's data base of information.

This aspect is also very important in the selection Of

the programming languages to be used. The preliminary

layout Of the data base forces the definition of initial
estimates of the number Of data base variables plus

dimensions of these variables. If large amounts of infor-

mation are required, then the use Of packed computer words
or random-access files may be required and, thus, the

applicable programming languages for implementing the

simulation model are further restricted.

Before the final selection Of the predominant pro-
gramming language, one aspect that is Often forgotten in
the early stages of the development Of the computer model

is the type Of managerial reports, including their format,

that will be supplied to the decision makers. Preliminary

layouts Of the managerial reports should be designed and

reviewed with tOp management. The initial report layouts

should not be overly sophisticated but contain enough

detail to satisfy the required categories Of target vari-

ables identified in the mathematical model. Preliminary

layout Of report formats forces a review Of data base

specifications to ensure the availability Of the necessary

data. If special reports are desired, then again the

applicable simulation languages are limited.

 

266

Finally, the selection of the predominant computer

programming language should be made based on a set Of
criteria similar to those in Figure 10 of Chapter II.

After selecting the predominant programming language, the

available compiler should be tested immediately via the

use of documented, sample problems. The basic features

of the language that will most likely be used should also

be tested. The above activities should be done if avail-

able programmers have not used the simulation language

extensively or recently.

After selecting the predominant programming language,
the next critical aspect in the design Of the computer

model should be the specific definition Of the model's

data base of information. Associated with this activity

should be the develOpment of the major subprograms Of

the computer model. By striving to get the detailed

specifications of the data base, the system design activ-
ities of Specifying subprogram transformations should
proceed from the abstract to the concrete.

In determining the dimensions of data base vari-
ables associated with a certain system activity, the

system design alternative that requires the least amount

of core memory should be initially selected. If this pro-

cedure is followed, the reliability of other components of

the computer model can Often be enhanced because additional

computer memory is available for sophisticated modeling
concepts.

 

267

In developing the detailed specifications Of the
computer model and ensuring that the data base is suffi-
cient for preparing the desired managerial reports, the
data base will be redefined many times. Redefinition is
often required because certain modeling activities require
too much core and/or processing time. By far, the most
frustrating aspect in the design of the computer model is
the redesign of the specifications of the data base. The
end result Of the data base definition should be the
assignment Of variable mnemonics plus the dimensions Of
each variable similar to that given in Appendix 1.

After designing the data base and segmenting the
model's subprograms, the programming Of the model should
move swiftly. The testing and subsequent merging of each
Of the major subsystems of the model facilitates the
computerization task. By testing each major subsystem
with the previously computerized subsystems plus skeleton
or basic activities from the remaining subsystems, con-
centrated effort aids in getting the model operationalized
and validated.

One last aspect in the computerization of large-scale
simulation models at universities is the beneficial use
Of undergraduate students for basic, academic research
similar to that conducted for the LREPS project. The
research project provided the students good training and
financial support plus provided the project team with a

talented group of programmers. Training was sometimes

268

carried to an extreme when their desire to become familiar
with some sophisticated aspect Of the CDC 6500 computer

operating system Often made computer programming tasks
more complicated and sophisticated than necessary. Their

desire for sophistication caused many tasks to be redone

in a simpler method.

Future Potential Research
An important area for additional research is the

potential impact upon model outputs resulting from alter-
native groupings and categories of tracked products.
Tracked products were used for pseudo-customer order

generation, inventory control purposes and inventory

management purposes. The traditional ABC analysis based
on sales dollar volume per product may not be the most

representative, categorical basis for estimating average

inventory characteristics. Weight sales, product density,

shipping characteristics, shipping and packing character-
istics are examples of alternative categorical bases.
Instead of using a multi-level manufacturing control

center and distribution center stage's model, a small-

scale, single-level system model could be used for this

analysis.
A related area Of research is an analysis of model

results using one categorical basis for grouping the total
product line but different samples of tracked products.

Different size samples as well as more than one sample of

the same size could be investigated. The purpose Of the

e-'

269

nmearch would be to determine the sensitivity of model

remflts to alternative product samples.

The validity of the hypothetical basis for calculat-
hm the sales modification factor presently used in LREPS

gflus the hypothetical basis for modifying forecasted sales

flumld be determined via controlled research. The present

relationship between speed Of customer service and fore-
casted sales is just one Of many relationships that could

be tested in LREPS. In addition, sales-to-service rela-

tionships that incorporate the consistency or reliability

of customer service could also be investigated. Consistency

of customer service may be more important than speed Of

service on realized sales.
The investigation of the bases that top management

utilize in making decisions concerning changes in their

‘physical distribution system configurations is an important

(area.of potential research. For example, the LREPS pro-

cedure for adding or deleting distribution centers should

km; validated. TOp management may not review and change

itxs facility configuration based on the modeled customer

service and sales criteria. Perhaps, cost considerations

along with the above criteria would be a more representa-
tive basis for changing the facility configuration in the
Combinations of customer service, sales and cost

rncndeel.
could be investigated for their validity and representa-

tiveness.
The next area of potential research is the effect

on the design Of the LREPS computer model if low-access,

“a? WET-T

270

extended core storage would have been available. The
possibility of redesigning the computer model to more
efficiently process the customer order file or store the
tracked product detail could have important ramifications
on the execution time of the model plus the compatibility
of the model among other manufacturer's computer operating
systems. Also the storage.of the LREPS operating system
subprograms used only on quarterly or less frequent basis
in extended core storage should be investigated. Large
savings in computer memory and execution time costs might
be realized.

From the computer programming perspective, an anal-

ysis as to the amount of effort to convert the present
LREPS computer model from GASP IIA to SIMSCRIPT II would
be beneficial. SIMSCRIPT II offers high potential for
large-scale simulation models such as LREPS. LREPS
requires the use of packed computer words of memory, the
use of auxiliary tape files of information plus the
ability to process variable-time activities. LREPS also
requires large arrays of information, many three dimen-
sional, for storing information related to the model.
The applicability of SIMSCRIPT II could be investigated
given the above system model requirements. The investi—
gation must be conducted in conjunction with large-scale
IBM 360 systems since the SIMSCRIPT II compiler is pre-

sently only available on those systems.

271

The use of LREPS as an educational, business game
could also be developed. Supporting teaching materials
could be developed that emphasized an understanding of
such concepts as the use of tracked products for inven-
tory purposes, the total and normal order cycle time
elements, and the five basic elements of a physical dis-
tribution system. Other concepts incorporated into
LREPS could be illustrated through the use of the computer
model.

The extension of the model to take into consideration
additional aspects beyond its present.scope could also be
the subject of additional research. Related to the pre-
sent LREPS computer model would be an analysis of the
computer memory and execution time requirements of the
computer model if analytical techniques, such as general
linear programming algorithms, were used as part of the
facility location subprogram. The basic question would
be the efficient use of these analytical techniques to
approach optimum locations concerning the DC facility
configuration.

Other possible extensions of the model would be an
analysis of the incorporation of other stages of the
total channel of distribution. Two possible areas would
be of immediate concern. The first possible extension
of the model would be the incorporation of the physical
supply aspects related to the MCC stage of the physical

distribution network illustrated in Figure 1. The primary

 

 

272

areas of inquiry would be an analysis of the computer
requirements and the possible use of present computer
subprograms or building blocks if this extension were to
be implemented.

Another possible extension of the model would be the
incorporation of activities beyond the demand units' stage
or the point of ownership transfer. To incorporate the
costs and service time requirements outside the immediate
system of control might have an important effect on tOp
management decision making. Again the computer require-
ments would have to be investigated and, assuming that
this extension could be implemented, the sensitivity of
model results to an extended system of consideration
could be investigated.

The next two areas of possible research are related
to the information system that was designed for LREPS.

The applicability of additional information system con-
cepts for LREPS could be investigated. The presently
utilized concepts that include supporting data system,
operating system, report generator system and data base

of information could be expanded to consider other aspects
of information storage, retrieval and manipulation.

Related to the LREPS information system is an
investigation into the further integration of its system
with business internal and external information systems.
The volatility of the model to a firm over time is a

function of the degree with which the model is an integral

273

part of the firm's information systems. Changes in costs,
elements of customer service, the marketing components of
price, product, promotion and physical distribution must
be easily effected through the model's data base for

model volatility. As part of a firm's information system,
the degree with which the model can be readily utilized at
decision points in time is critical.

Related to the integration of the model within busi-
ness information systems is the timing of the updating and
revision of the information utilized in the model. The
assistance given to management is only as good as the data
inputted into the model. How often the model's data base
should be updated could be investigated.

The last general area of possible research is
related to the aspects of project management for research
similar to that conducted for LREPS. LREPS was developed
as basic, academic research utilizing a faculty and student
project team. Further research could focus on an investi-
gation as to the effectiveness of such research in a
university atmOSphere. The project research generally has
a secondary position in reference to the student's goals
to obtain a degree.

These areas of potential research are exemplary of
the benefits achieved from a large-scale project conducted

at a university.

CHAPTER IX--FOOTNOTES

1Control Data 6400/6500/6600 Computer Systems:
FORTRAN Extended Reference Manual, Control Data Corpora-
Eion, Palo Alto, California, printed in the United States
of America, 1969.

 

 

274

SELECTED BIBLIOGRAPHY

Asimow, Morris. Introduction to Design. Englewood Cliffs,
N. J.: Prentice-Hall, Inc., 1962.

 

Bowersox, D. J., et a1. Dynamic Simulation of Physical
Distribution Systems. Monograph. East LanSing,
Michigan: Division of Research, Michigan State
University, forthcoming.

 

Bowersox, D. J.; Smykay, E. W.; and LaLonde, B. J.
Physical Distribution Management. New York:
The MacMillan Co., 1968.

 

Buxton, J. N. and Laski, J. G. "Control and Simulation
Languages." Computer Journal. Vol. 5 (Oct., 1962),
pp. 194-200.

 

Clementson, A. T. "Extended Control and Simulation Lan-
guages." Computer Journal. Vol. 9, 3 (Nov., 1966)
pp. 215-220.

 

Control Data 6400/650016600 Computer Systems: FORTRAN
Extended Reference Manual. Palo Alto, California:
Control Data Corporation, printed in the United
States of America, 1969.

 

Efron, R. and Gordon, G. "A General Purpose Digital
Simulation-Description." IBM Systems Journal, Vol.
3, No. l (1964), p. 57.

Helferich, O. K. "Development of a Dynamic Simulation
Model for Planning Physical Distribution Systems:
Formulation of the Mathematical Model." Unpublished
Doctoral Dissertation, Michigan State University.

Kiviat, Philip J. and Pritsker, A. A. B. Simulation with
GASP II: A FORTRAN Based Simulation Languag_.
Englewood Cliffs, N. J.: Prentice-Hall: Inc., 1969.

 

 

Kiviat, Philip J. Digital Computer Simulation: Modeling
Concepts, RM-5378-PR. The Rand Corp., Aug., 1967.

 

 

275

276

Kiviat, Philip J. Simulation Language Report Generators.
The Rand Corp., April, 1966, p. 33-49.

Kiviat, Philip J.; Villanueva, R.; and Markowitz, H. M.
SIMSCRIPT II. Englewood Cliffs, N. J.: Prentice-
Hall, Inc., 1968.

 

Krasnow, Howard S. and Merikallio, R. A. "The Past,
Present and Future of General Simulation Languages."
Management Science. Vol. II (Nov., 1964), pp. 236-
267.

 

Krasnow, Howard S. "Computer Languages of System Simula-
tion." Digital Computer User's Handbook. Edited
by Melvin Klerer and Granino Korn. New York:
McGraw Hill Book Co., 1967, Section I, pp. 258-277.

 

Markowitz, H.; Hausner, B.; and Karr, M."SIMSCRIPT" A
Simulation Programming Language. Englewood Ciiffs,
N. J.: Prentice-Hall, Inc., 1963.

 

McNeley, J. "Simulation Languages." Simulation. Vol.
9 (Aug., 1967), PP. 95-98.

Naylor, T. H.; Balintfy, J. L.; Burdick, D. S.; and Chu,
Kong. Computer Simulation Techniques. New York,
London, Sydney: John Wiley and Sons, Inc., 1968.‘

Parente, R. J. and Krasnow, H. S. "A Language for Model-
ing and Simulating Dynamic Systems." Communications ACM
Vol. 10 (Sept., 1967), pp. 559-560.

Tocher, K. D. "Review of Simulation Languages." '0 era-
tions Research Quarterly, Vol. 16 (June, 196SE,
pp. 189-218.

 

Teichroew, Daniel and Lubin, J. F. "Computer Simulation--
Discussion of Techniques and Comparisons of Lan-
guages." Communications ACM. Vol. 10 (Oct., 1966),
pp. 732-741.

 

Teichroew, Daniel; Truitt, T. D.; and Lubin, J. F.
"Discussion of Computer Simulation Techniques and
Comparison of Languages."‘ Simulation. Vol. 9
(Oct., 1967), pp. 181-190.

 

Underwood, R. S. and Sparks, Fred W. Analytic Geometry.
Boston: Houghton Mifflin Company; Cambridge:
The Riverside Press, 1956.

 

APPENDIX 1

DATA BASE INFORMATION

277

278

The data base of the LREPS operating system is

listed on the following pages. The coding scheme for

each column of information is:

l)

2)

3)

4)

Column one, "NAME," contains the name or
mnemonic of the variable. If the variable

is multi-dimensional, a more descriptive

name of the array is footnoted at the bottom
of the page.

Column two, "COL," refers to the dimensions
of the variable. If the variable has only
one dimension, then this column is blank.
Multi-dimensioned variables are given a
number from one to n for each of the n
dimensions of the variable.

Column three, "DLT," refers to the delta-time
unit or frequency with which a variable can
be changed. "C" refers to cyclic; "A" refers
to annual; "Q" refers to quarterly; and "D"
refers to daily.

Column four, "TYPE," designates the variable
as either exogenous, "x," or endogenous, "N."
The "N" variables could have been set exogen-
ously at the beginning of the simulation
cycle. During cycle execution, the "N" vari-
ables are only altered within the operating

system.

5)

6)

7)

279

The next four columns, "M&C," "OPS," "D&E,"
and "MEAS," indicate the data base variables
used or altered by the model's major sub-
systems. "U" signifies that the data base
variable is only used by the specified sub-
system. "S" signifies that the data base
variable is used and altered in the subsystem.
Column six, "MODE," signifies whether a vari-
able is "R," a real, fractional variable, "I,"
an integer variable, or "P," a packed vari-
able containing more than one piece of infor-
mation per computer word.

Column seven, "CONTENTS," is a description of
the contents of each of the variables in the
data base. If the variable is multi-dimen-
sional, then each dimension or column of the

variable is described.

 

280

coupe azuen .0 amQUOLQ wcu :« a.oo Ho Lanedz

nods: passes a.cc«m¢u on» new maudvcd wannabe: 2:» mo Eda
v.00 unoccudlc« how uc¢Eu¢c>cfl ucdaoo puzoaad Edsaxcz
:.00 Ca unoEnmd>:« uadaoc so3oaaa EdELXdz

ou~>uom uDEOumdU mo Hm>o~ Ucuameo

madam u20w33 .u0360u1 ononuu 0&0

nwuoaop on ccu Dan» «.00 mo LonEdc EdEAxaz

Guava on ado uacu $.00 no udgfidc Edeaxdz

Ewumxm aw pskofifla a.Uo uo nonEdc EdEmez

moaom umpuo wucCuOunuwuLme

mwfimm mafia ouncuODnuwuucdo

ammcm wmwu mums‘ouuuwuscdo

moawm wndo OumCIODououume

madam armed) mumpuounuwuLMdo

mwfiam ucmmoc oucc10upuwuuado
mxsaop DUdVOum addca>wpc«

wzu mo chads» 0:» ac Eda 02a Seuu noudQEoo ad 20%;: moaon udoxUODm on» we ccflu04>oc cudvcaum
mxcfiop uUdUOum Hcdpa>apcfi

on» yo Eda on» Eouw owuddeou ma nods: .udo coxUODm padooum a co>aq .maaov udoxUODm omcuw><

cauduoua poxuuuu onu u0u Odo» nuMCd ammo HauOD wnu uo monocuoxomn mDMCd omeo yo uceouwm
Lvuuwdw and” on» Ca

unocuo any Add new we no ouadwu onu uo Eda ecu 80uu woudnEoo nu Lodz: v9 mo coauda>op Unapccum
ucuundq umoa on» an nympho

Add uOu m.v9 on» uo Edm on» Ecuu voudQEoo mu scan: Away oawu coaucDLOchmuu pcdonudo wmduw><
keypadv umaa ecu ch nympho AHc new vb + ~& + as no wucdvm

wcu mo Edm onu EOuu vmudQEoo aw Lodz: uEwu mauxo Lethe wmauo>n Awake: and mo nodua~>op Unopcnum
uoauddv umna OLD Ca muopuo

add new v9 + NB + He 0:» «o Eda on» EOuu cuudmfiou ma umnu oEMu macho uwpuo wmsuw>w HdEuoz

noucvo cofiudnwuunwp mica uo hufiodmeo uuHHOp moamm on» mo uOumufiocH

mafia dachu uwcuo aduOu cadum><

newua>auuq n.u0uuudv Damn ecu new umou coaudnduumqp “acqm>na Hauoa

coho oficmmuoouo «.va nan» c“ mafia: vcnfiwp onu new moudncH voucofioz ozu no Edm
nuqauo>e >HHMwucwcomxm

numuuuaou Quad. voucadfifiw Uo azacwELODDp Cw cum: uOuuaw noduaoqufipoe moadm

on menu Cu pmcmwmmm mafia: pcanp uo uandz

cowud~0u1c« am wen» :oflumooH on Hmwucwuoa ecu No @600

Anhv wfiuu xuaccwm quuoxoun coucEAXOuQQ<

camconu xuwoaaau mud no pancaop .Umppc mm: on a cor: GENE
moawu unwed) xauouucdv commuo>c xaduflucmcomxm
noauu unaaon >Hu0uum:v cwomu0>m xaaufiucocomxm
v8 6:0 «B aucofioao OEwu ouH>uom uoEoumdu uOu mucuwofivcfi Dom mafia ommoaflz
0000 DCOEcmammn Dom mafia on mo vmxe
v8 .NH .Hh uOu uuUUCwom muccflum> wfiwu wufi>uom quODmdU
ucouowuuoou an. o>onn onu new .Nmu uoaufipos wuau cedumuuoamcouu Hnwm
Demuuuuuooo no: o>onu onu uOu sax. uoamflpoe ouch coauauuoaucwuu deem
mucounww
co Deana mauau noduuuuommcuuu undonudo any maunadono new con: ucofiowuuvoo an: manofiuc>
nouou newuouuoaucouu nadonudo on» mafiuaadUHuo uOu pond Deodoauuwoo no: ucmuucoo
ovdufimcoH on» EOuu oeuuo>cou causapuOOUn» unadocmuowm
acdufiuaa 0:» Sega umuuo>coo cumaouOOUIx unadmcauowd

on unaa Haquuoa on» uOu acadom ea madam oDQUIODIuouuadO

on ocfia Hadu onu new atedoa Cu modem oanIOuaMOuuudo

on mafia Andaman on» new modem uo-op cucpnOuuuuuucdc

0a cada Addu gnu new madam uaHHOp ouocn0unuouuudo

Uo ocwa fluauunm any EOuu cocauuan auznufl: pouuadu~ao

on Dead Hadu 0:0 Eouu wocnumav >o3£mqn neucHDUHMU

mandom :« noama mauouuadv pwmauo>o mdquaucwcomxm

moan: ud-0fl hauouumdv cwmcuo>u kaHMADCQCOqu

poxcaa na 0600 so noquu on» scan: Ou mound on COADdHowucw ozu uo low on» mca>uwucopfi coco
:o«unUoHHu woman new n.30 kHEOflccu meauuoawn uOu pond x06:« UmunmwOJ 0>Muu~dEdU

on nodudHOnaCu Ou pocwamnn n.3o new opou so oeuuom

00m auscuouu new v9 use on pucmannu aauonufi uOu v9 a as anonfidc wean mafia wofi>uon umEOumdU
ceauuoomau madam new bond chcfi pousmwos

>uqo as: new uvduwmco~ scum pouuo>coo ouMpruoounx unadmcauowz

undo Ad: new ooduuuau EOuu wouuo>coo quCwUHOOqu nuadmcauoma

auOudUapcw noecuado Hafioomm

nucoucoo

HHHmmmmmH
3:)DInDZDDIDW
X:K)<23<><X::Z
<3C’OCJOCJCIOC)
ammvmohwa‘

Gui

:JDIDDZJD
unmtnuamcn
mcnuam:nu>
2 2521125212
QCJDIDCID

0‘

H

m
U)
m
D

ma

ea
ma

uam
01W
222
CID

m N‘: a m:zn:mczm
mcn

W
m
m
2
O

NA

1
m
m
m
z
D
A
0‘4

K
W
m
m
2
D
O
H

I‘lfliltl
UIUID(D
DID
UIWIOU)W
2:22:22:
m~or~¢>o

U33
3': D
P‘hiF1Q

MmHUQ

a:m:x~:m¢za:m “bard!
:’:):>D D‘Diflin uau)m m
F‘X3x X X:Z:Z:B z z z z

DID I):

D:D:>D
x2<><x

moo

3:3
Man)W

3:33
UL)U‘IOCJOC)OCIOC)OCJQCI LJULJU UL)U()OC)OCJ CIOCJO OCJOC)Q

KllflillhhdflrdflIK03¢¢iflifllfi mcza:m
3:3

D:3:>D(nu:m¢nuam:nu:m:nuam

X><7¢XIZ252122325325252222

PQFIF)"V)¢’F~C’O\

Do

2C30ln
:hl‘ln
Q lid
C>n.m
Z‘JL’
F>'mlfl
0.)?
0(34

 

.coHquLOucH omen cuoouu.~ xHozumm<

 

 

38. 8:813:54 uuxuonw

Adoovamunllxcwd concoum UUEIUD adducouomna AAOUVUUIIInDUCOU aouucou aflakduuuuaafllm
~AOUVZEZFQOIqu0uu4602 calm vauuauomvz AICGMH uzdonu=Ooa .400.Um¢nn~ufl0«omflc
AAOOVUOHUKAIIUQ >A >k0wouuu u0560uma AAOUVwMUDIICO«u:~om Ca o.Uan

.aouyuaxmuuua >2 aqauoa uUdUOumn AAOUVAUOIICOuuuuoq on alqunuuomu

Aqou_aozmnn>uouuuau >hauzo>Cn >2 nuuuun uUduoump Aqou.:n«uu«:= vanadna

hAU
Kdmhmu

uncuuuu oca>aa uo u-oo uo auauCOuom
macaw nacho Mom oa>u uaEDu-du homae non nxuofin nacho uo uwnEdz
a ufiuquwmn u
ovu>nan :10 uunu .>uau0unn unanu0uuou :4 .I.uo Oahu-50w on» acacquucou acne: noudeoo uaxoum
anew» ouq>u0u amou0>o >au m on: ~ .A new nuou anus owau~wa noEOundo c>«ua:uuu~<
nuOuu~dEduuu ucwfimqnn on any new dewun unoawl Edfiaxqz
our sons scum uncouunnau u:wsnazu new uxmann unmauz Edsaxn:

H“
D

zumtua
uzuz

x x x x x x

meUt

 

Incuunu 0E4» vascuku we: ufiqu newuuafincunu nounowu vcdoncu
xcdd .a:» .«> uoadmms. an Add: «as» Davao: dado» no coauuoaoua
uo uuuucouom you out cauauona a Cu noxcqa anodcoum noquuu any mc«:«uu:00 who: uoudeOU voxuum

33:? DD

:OAwou >A o:o«u«uuooo In. ecu uo noduquoa v2
:odoun an ucoauquuoou .u. on» co unauanoa mm

D D D D D D 3 D D D :

le —IN N
A

uuduOua noxuuuu >2 nan: undo nan unmflo: wmnuu><
unduo~n ucxuuuu >9 van: onuu hum andu umuuu><
vodvcun uwxuuhu >n aqua ouuu uoa vac. nuoom uo uuoo
nuudu0um uoxuanu any new vac. nuacd ouou uo nansdz auuoe
manna undocun vuxouuunu>uooouau >3 mk aEau oun>non quOundu unuueqxounmc uzu
uam cu Iowan vac: nunu auuou >n nonu>uv on aaal cows: mound wuuu udonvoxUOu- uuuanmauzaauEAH
uuovMOUn unaccun|0uucwn ouuUIOunuouuudo
nudoxUOu- unannouluounado

mmm W33: :3
mmw mpg:

bUDkOflm

 

281

caducnu-udo >auco-aun a“ uouuoou a aura anuu«uc« :a mafia Roam. >uqu=udu nucnoom
udoxuou- a :o>«m udo coxuou- :uon uun unaccum n unnu u>uo «o quEdz
and: :0 >houco>nn
>10 nan >n0ucw>ca unuOu umunu>q
0:» mcauua=U~uo :« van: unmuaucddu unquOu acqucnu-udo Idam van: :0 >h0u:n>=« vouuumouzdlwfiak
~C>0uum acufizuwnuanoz
A~moz. n u:«on nounOOM 0:4 .Amox. a u:aom noquOH m:«:«uu:oo final nuadeou uaxonm

h z I z N I a H z I z m m z z m x A z I x a
vmw Hun

DDln mmm munm In
222 222 222 zxxx xx XXX

mm": m
H N n

unfit

>uquom o>onu new wove-u xoouu >u0uum

>ouaom «>00: uOu :umon vauuom Ila>oz

>U>Hom >h0uco>:« no on>k

acauno-Oumou Ia >nomluuu nun» unnu nuodu0um wo nomad: snack
>hou0uuu nag» ken I600 dance undocum acmwcm

>hdm¢auu can» now oven Adana unduOnm mcwccumom

n_uo Ocaa ”vacuum >A ocuucun naquomouuu 0;» no ununuaucm

UUUUOOO 000 DOB ODD oUUU UU UUO 0000 00

a u a H H I I
a
DD: :33
3:33:33:
XNN’6XXX
H N n v m w h

«DKA

“canon zo~>ou unasfiuza voaduozou u-nn any zany“:
unnuuanauv :cun us: u:o£&«:u a unsung: «a neuuu«u:« :a ndun no: on» ya Leone :0 uzmuol «duos
out ogu an ucav:auuudo and away InevuOOh undocun cunuuade ua nonadz
on any
Ecuu out any at novuouu :0 >uuco-oum an: aura duodvoun any m:«:duu:ou who: neednEOO woxoum
oaqu wand
uucuoon nouul>n on» mcauaadoauu uOu can: hound ndam weuu v.04 novuoou ~qu0u uuvuadsdou<
ukuvuouu uo:v0nn|oHn«u~=a uo uonEd: usuOk

a I m H I
m m m u a
a N n v m

 

out a an nuance» uuapOuQnflamquadfi d u:m ocean can mcauunuum no unou
I>Ic no gonads :« :o>«m ad ausu >0Muom scunmuau ucofinazn vuaduunuu 00:
omnu- out on» us unovn00h mc‘nnmoum can unauuuooum new haucaom aocnuuu> N9

XXN 22 z 22

bOH I
D
D a
D D a m m
Hoan

cauudao-Icw >«uco-0hn an. aura -.Un no nuanflz
uouuudv and» and uo>o namuu>auuu now 9.00 unaudnwuuuav aqua->zn «duos
nucdom :« nexu- uudvoum waxuvuu on» ca noduu undocum «quu no aqua:

denudao- :1 -.on new u:0Eulo>:« u-HHOU aauoh
vauoHou manna uo Innuenm one :« u.ua uo uonsdz

00000000 000 GB D all
h
H

N
O
u
5
U‘
U
D
I
w
0
E
u
h
0
m
’D
O
>
0
a
.C
u
u
0
o
«a
>
M
C
I
.4
a
5
42
0
¢<
Hlfifififll‘u
Ill
nmmmmmmm
22122222

 

 

 

 

 

282

 

 

 

 

 

 

 

 

 

>HHauHumcecc m.ua maeuouancH Ho Loafid: EdEdez H a x O m<inE
>H~cc.bmofioc Us3cHHd a.Uo Ho H24Edc EdEthI H R x o muar<z
on; a EOHH >HHdv vuaaHza an :50 ans» Imam ucHHcc cczu mmeH whetto quOumdo Ho padouom m D D x o ;:mu
m.Oca on» ECLH mucoEdanm >HHap uoH pouochcoo on coo bozo gnaw uzvemHLm ucHHoc EdEde: m a a x 0 222m
OEHu ficucHdEdm Ho pnc> H 3 m z t z<L>H
unoUOMOu HuHHOU moHcm OHumoECU Hddccc «MDCH m D D x ¢ mas?
quHHoac amo a anode? od wad» saHoo m a x o morass
>uHHHoaH m1oax a oqucd cu weds xodwo m a x o alreao
>uHHHUdH LIUQK d mudeU Ou OEHH >cHOO m D x U szyqo
>DHHHosH Emu a and Cu 06H» >quD m D x U a0293<
>uHHHucH apuam a con Cu oEHu >dHco m D x U Qazab<
>DHHHUcH muuoz a con OD oEHu >mHoa m a x U szez<
Hdm> tum m>ucxt33 nmudeEHm Ho Hunfidz H D D x U m>2x32
pauwHop on can umcu moHuHHHUaH :H acoEumo>cH uoHHco uHuonoc EdEHxnz H 3 x u mzinz
m.UQ coHudHOmncH you ucoEumo>cH unHHOp oHumdfioo EdEHxa: H D x U mszxz
coHDHOQoudu-omucco ccH>uucu >L0uco>cH >HHca m D D x u OQHQ
ounHuo> UQHHHQOE no unaumcoo a mH cuedu umem >HHac uHumeCp wzu baryon: ocsudthca qum H D D x U unimae
pameOOHQ mcHon ccHooL Ho HonEdz H D D m 2 Q OzcmzH
pommOOCLQ vcHon m.Do Ho Handc Hence H a D D x L $222
moduOOOuco >L0uco>cH Ho gonad: Hmuos H 3 D D x U OazeH
oHo>u uoH muudUOHQ poxomuu Ho nonEdc Hanoe H D D D x U awzeH
EzuHuouHc coHuoOoH Do wcu cH> cocoa 09 Cu m.Uo HO umHH >HHHOHHQ HdcoHoom H D x O mummy:
mwucwHuu> OEHu ccwH Locket» can udECumdo ocHuaumccm Lou mCOHDUCdH oocnauc> 06H» ouH>uwm m D D x O Zx<a
muco>w wEHuupwaH poHdeLOm ecu uoH muonEdc ucw>w dam >do H D x u :Lmz
uUdeuQ pwxoauu Lona uoH cameos uUdeua uHumoEOU HcDOD pommum>c >HHcHucscoixm m m z o N
uOdCOHQ coxucuu £050 no“ vcmewc UHquEOC HnuOu wudvscu-Hauundo m m m 2 O H 0.xxadF
mmnHU unoHoz
>3 m.Uo :oHudHOm-CH 0:» Cu m.uuz wzu Ho cogs EOHH commacm unmaoz mnu Ho muouaHdEdoo< m 3 m m z 0 HUOIOQ
mmoHU ucoHoz >n m.Uo coHudHOmacH mcu we come EOHH UwamHzm unmao3 ozu Ho mucudeEduo< m m m z o ZDU<F3
m>an HH Use a .h .m .m CHLDH3 mumnuo Ho mcoHquQOHH m m m m z o N
a>ac Ha new a .h .m .n :HnuHJ muqHHOC mesm Ho coHDHOQOud m m m m z a H HLmHQHDO
muowadEdoou medm uonoz 6:6 HaHHcp >Huwuuddd .UHumeOQ x m a z o 4<m233
mucuoHdEdoom meom ucho3 pad uaHHop >Hucuucdq .Hacchwm m m a z 0 U<momx
umou mcHHpccz pan mcH>uuau >u0ucm>cH a m 3 z o o
umoo >uHHHoom x m 3 z 0 m
umou mcoHuaoHCdEEou m m D 2 o v
umoo unarmsoure x m a z o n
umOu :oHuaDHOchnuu UCdOQCH m m D 2 O N
umoo coHDMDHOEmccuu tcdonudo m m a 2 o H whymoouo
soda ocHH and uaou wanadum> m s a x o m
“echo uwa umoo oHanum> m D D x O m
Leuuau umou cwxah m D D x o H m_uxzou
0Q>u UQ can QNHn >3 nuaHHon ucwEunm>cH ommuo>< m 3 3 x O Emu>zH
oa>u can vnHm 00 >9 ccdoa boa oumu umoo udaLmJCHLP m D D x o Udath
movducouuoa uHHam uoHHOp uOEOumdo Hdc0aoom m D D x O maacmo
EwuH wcHH Han unoo anoHum> m D D x O m
uwpuo non umou ancHum> m 3 a x o N
uOuoeH umoo poxam m D D x O H v_cuzzou
EouH ocHH umm umOU oHanum> m a D x o n
nacho pom umoo oanHuo> z D D x o N
uOuuoH umoo dome m a a x o H mimuzrou
aneHo uzodwz >n noun» Braden“ ooz-oo Haducouoa m a s x 0 wave
00 Ho muHm >n uchuumcoo >uHUMQaU m a D D x o Unduuc
mascara cwudeu a.:oHuauH:dEEoo H D x o m
neocono mcHHccms mHgHuoumE Ho coHucNHuHCD H a x o v
moccanu >UHHOQ uceewmmcne >u0ucw>cH H D x o m
mwmcnnu poumHou :oHumuuommcnue H D x o N
66H“ moocano suHHHouH cm H a x o H «.moaH
mucoucoo m w m m U m 9 A 0562
o < a m a m A O
o m o o z > a U
z z B

 

.codcducoouu.H xHozuma<

283

HAOUDHHUQMOIIQDOHU >n HHquQ onHm HOUHOmH

quuvzmomenuvcuevo uUdpon oHumeOD

AHOUDQUZZOUIImumOU 2200 UHumOEOQ

HHOUDUZZOUInOQ>B on Dan 0NHm >9 numou 2200 DD HuHucwu0m

mH

 

 

 

mH vH
HHOUVmHDFUOIIncoHuuomon OEHB oHU>U HODHO HMEHOZHH HDOUVmUXXOUIImumOU 2200 HMCOHDOKMH
HHOUDHmouua--aoHuH>Huo< an HoH umoo on :oHudHomncHoH HHOODHaaHunnmmcuzu sounxw HoH momHH canon: namH
kuucdv mHnu mmwoon OucH uda m.UD Ho HODEdz m m 2 O zHoDz
m.UD QHDHmHHo HOH monm DD pouomaxo UD Ho Edm m m 2 0 szUD
«.09 can aconwH Ho mumHH mcHxHox Us: How can: HaHH< m m z o Hdem
oHumu >uHOmano mvHum ou HaHHOU OD x m 2 O oHe¢xm
acoEmHUcH uncooHoH monm uHumeoc >H£ucoz m m z 4 qux
umoo ocHHwDHo uodpoum UOchHB m m z o hmoomo
>uHucm3v Honuo UHEocooo undpoHa poxoauu OD x m z 0 00m
xUODm Howudn uodooHd noxucHu on m m z o mam
on Hon uccfiwv >HHup m>a uUdvoHd waomHu Ho coHucH>op cunpcaum m m z o Dam
numcmH OOHHOQ 3vH>0H Ho :oHuoH>op DHMDCdum m m z 0 mxw
wEHu pmoH HocHooH Ho coHuaH>wp cumpcaum m m z 0 94m
pcmfioo >HHaU ommuw>a uUdUOHd poxomuu on m m z 0 two
Hououu coHuooHHHvofi noHua Uo mcHuanoHno HoH pond :oHuHomon ooH>Hom Ho Ho>vH Hnduom OD x m z o meo<uo
meam ucmHoz HacovaH QHO Hench m m z 0 HkxDm
Hmvoocmnu Ecum>m om Ho HODmUHUCH H m z 0 ozumom
ouHCd oHnmonOOD HHm HOH wcHH\umoo oHanHc> Hmuoe m m z o 40>
auHCD OHLQmumoam HHM Hou H0OH0\umou oHDnHHu> kuoa m m z 0 00m
muHCD qummHooom HHm HOH umou DoxHH HauOB m m z 0 DH
moHuokumu uan03 031 Ho Honfidz m m z 0 mDO>H
meHooeuno ucmez Don Ho HonEdz m m z 0 mDo>H
HouomH DOE muau ucmEdHnm poHoom Una z m z o ULDOOH
uanoB pwuquEdouo .>HkuHudv DD Cu 00 m m z o 93
oucaume DQOH DD OD on a m z 0 BmHD
HobomH :oHuowHHoo oueu 0Q>unoa m m z o mum
HoHHHUOE :oHuuHOQMHuxo >Hoqvuoo >H0uco>cH m m z o to
him HOH new: kuwfidumm :onHumU 900 Have» HOEODmdU m D D x O zOU><D
HenEdc :oHDQUHHHucprnUDH Ho owaHOuu >Hmuoasmb H m z D HIMBUDH
meQm Du pwuauoHHc xooHn HopHo Ho ucouuom m m z o DADA
on mcHHIHHdH On unuoooHHa xooHn HopHo Ho accouom m m z D Umoom
HHouwp undpoum Umxunuu xooHn HOUHO m D D x D v
dump >HuEEdm mecm Hocuo Hunuo m D D x a n
>HnEEdu uanwz monm xooHn Hepuo m D D x a N
>HuEEdm HuHHOD noHua xooHn Hopuo m D D x D H >_Amoozo
aconoH :oHudHOmncH Ho HwnEdz H D x o moumz
n.00: :oHudHOmocH Ho Hobfidz H D D x o mouzz
HHHHHuaH on mcHuono co occaxo on 02H» HaHon a a x o masze
>Huouuodu can >HHoUHuumsOp pound on :60 umnu a.uo Ho anfid: EdEchz H D x o DD<UDz
o.oo Ho oo< :H new: on ou enuHHomHo Ho wax» 0» on mmHH H D x o o<mmra
uoc Ho mconHuoU on no nuchHumcou HccoHooH On an ouHm H D x 0 2000mm
uoc Ho aconHoov Do :0 mucHuHumcou oHummEOD o» no mnHm H D x o zoov<z
Han HoH aoHon nouuHssHu on m m z o mq<mua
ufiEGumdu Honos >n HauquEdoon HcHHoc uuHum m m z a u<memu
HOEODmdo moans >n :oHumuoHHa HnHHoo moHom x m z o H<m9mu
on can DD >n noqucH vauanOB ouquEduum 0» pond oHnaHHm> m m z c UU<H3
HOEOumdu Henna mqu HoH mxuoHn Hocuo Ho Honadz H m z o memH
voauoooun axooHD Hupuo HoEODmdU anon Ho anEdz H m z o qummH
commuuon mcHon om>u HwEODndo Hoflmz H m z D mm>FUH
:oHuouoHHo noHaa n.uoSOumdu a cHouuu Cu uwHHHUOE xooHn Hopuo a m z a :mo
pououHou >HEODcou soon as: udzu xuoHn Houuo Ho anEdz H m D 2 o KUODDH
pomnooon mCHwn Hopuo Ho Honsdz H m D 2 a DuoH
uuououoH HnHHoo noch >HHmc uHuaoan z m D 2 a Own
:oHusHou cH uou ocHwn on Ho wooo H m z o zucooH
coauoUOHQ ocHon on HuHuCOuom Ho ovou H D D D m z a HOZUQH
concououa mcHon Do coHUdHOuacH Ho Hunfidz H D D D m z D OZUDH
ucoecoHnno on ace-cum :0 Donna commouon ucHon Do «0 HonEdz H m m D m z D HOZDDH
nonuououn mchn do Ho Hangsz H m m m z a czsoH
HHHouHuaoeoo nouoHou mcHon u.oo muoooum-:H Ho Honssz H m z o manmzz
Houuadv anon HOH 05H» oHo>o Honuo Have» omuue>d uHunaEOD a m m z o km<zoa
Houuadv andH uo>o Eouu>n on new unou Hauoa m m m z o amoeba
sounxn on :H a.uo Ho Honsdz H m z o moors:
Eouu>n 0» pound unHon -.UD :H acoEuuv>cH uuHH0p oHuaoEOD H m z o mmm>zH
u.UD 2H mucoEuoo>CH HcHHoo oHunoeov Hmuoa H m z o mkm>zH
HHHuoHuuoeov cocoa mchn ..oo aaououa-cH Ho monasz H m z o mmszz
unuoon :H UO3OHH6 u:o&v-o>=« uaHHoo OHuowfioo EdEqu: H D x o mm>Hxx

APPENDIX 2

RPG DC-BASED SAMPLE REPORT FORMATS

284

* *3fifi'*i*3b* %3&% i

**************************************************

* ***** ****** ***** *****
* * * * * * *
* ***** **** *****

*****
* * * * *
* * * * * *
****** * * ***** * *****

**************************************************

LONG RANGE ENVIRONMENTAL PLANNING SIMULATOR

MICHIGAN STATE UNIVERSITY

285

$39* *3P$!*I-*3&* *

286

TABLE OF CONTENTS

END OF CYCLE SUMMARY

QUARTERLY SUMMARIES

DISTRIBUTION CENTER DETAIL REPORTS
SALES REPORT
COST REPORT
ORDER CYCLE TIME REPORT
REORDER REPORT
INVENTORY CONDITION REPORT
IDENTIFICATION REPORT
NORMAL ORDER CYCLE TIME REPORT (DOLLARS)
NORMAL ORDER CYCLE TIME REPORT (ORDERS)
WEIGHT CLASS ACCUMULATIONS REPORT (DC TOTALS)

WEIGHT CLASS ACCUMULATIONS REPORT (MCCl)

4-43

44-ON

287

LONG RANGE ENVIRONMENTAL PLANNING SIMULATOR PAGE 3
MICHIGAN STATE UNIVERSITY
DATE 09/05/70

END OF CYCLE SUMMARY

DC SALES COST PROFIT OC TIME INV OH

LOCATION 1

LOCATION 2

LOCATION 3

LOCATION 4

LOCATION 5 WAS NEVER IN SOLUTION
LOCATION 6

LOCATION 7 WAS NEVER IN SOLUTION
LOCATION 8 WAS NEVER IN SOLUTION
LOCATION 9 WAS NEVER IN SOLUTION
LOCATION 10 WAS NEVER IN SOLUTION
LOCATION 11 WAS NEVER IN SOLUTION
LOCATION 12 WAS NEVER IN SOLUTION
LOCATION 13 WAS NEVER IN SOLUTION
LOCATION 14 WAS NEVER IN SOLUTION
LOCATION 15 WAS NEVER IN SOLUTION
LOCATION 16 WAS NEVER IN SOLUTION
LOCATION 17 WAS NEVER IN SOLUTION
LOCATION 18 WAS NEVER IN SOLUTION
LOCATION 19 WAS NEVER IN SOLUTION
LOCATION 20 WAS NEVER IN SOLUTION
LOCATION 21 WAS NEVER IN SOLUTION
LOCATION 22 WAS NEVER IN SOLUTION
LOCATION 23 WAS NEVER IN SOLUTION
LOCATION 24 WAS NEVER IN SOLUTION
LOCATION 25 WAS NEVER IN SOLUTION
LOCATION 26 WAS NEVER IN SOLUTION
LOCATION 27 WAS NEVER IN SOLUTION
LOCATION 28 WAS NEVER IN SOLUTION
LOCATION 29 WAS NEVER IN SOLUTION
LOCATION 30 WAS NEVER IN SOLUTION
LOCATION 31 WAS NEVER IN SOLUTION
LOCATION 32 WAS NEVER IN SOLUTION
LOCATION 33 WAS NEVER IN SOLUTION
LOCATION 34 WAS NEVER IN SOLUTION
LOCATION 35 WAS NEVER IN SOLUTION

TOTALS

288

LONG RANGE ENVIRONMENTAL PLANNING SIMULATOR PAGE 4
MICHIGAN STATE UNIVERSITY
DATE 09/05/70

SUMMARY FOR QUARTER 1
DC SALES COST PROFIT OC TIME INV OH

LOCATION
LOCATION
LOCATION
LOCATION
LOCATION
LOCATION

mmaa-ri-J

TOTALS

289

LONG RANGE ENVIRONMENTAL PLANNING SIMULATOR PAGE 44
MICHIGAN STATE UNIVERSITY
DATE 09/05/70

LOCATION 1 SALES REPORT
R DOLLARS WEIGHT CUBE CASES LINES ORDERS

\DGJNIO‘U‘IJHWNI-‘i—J

290

LONG RANGE ENVIRONMENTAL PLANNING SIMULATOR PAGE 45
MICHIGAN STATE UNIVERSITY
DATE 09/05/70

 

LOCATION 1 COST REPORT
QTR OBC IBC TPC COM FAC INV TOT
1
2
LONG RANGE ENVIRONMENTAL PLANNING SIMULATOR PAGE 46

MICHIGAN STATE UNIVERSITY
DATE 09/05/70

 

LOCATION 1 ORDER CYCLE TIME REPORT
QTR TOT OCT BO PEN NOCT SD NOCT OBT SD CDT
1
2
LONG RANGE ENVIRONMENTAL PLANNING SIMULATOR PAGE 47

MICHIGAN STATE UNIVERSITY
DATE 09/05/70

LOCATION l REORDER REPORT
MULTI PRODUCT AVG LEAD TIME
QTR MCC 1 MCC 2 MCC 3 MCC 4 MCC 1 MCC 2 MCC 3 MCC 4
l
2

 

LONG RANGE ENVIRONMENTAL PLANNING SIMULATOR PAGE 48
MICHIGAN STATE UNIVERSITY
DATE 09/05/70

 

LOCATION 1 INVENTORY CONDITION REPORT
QTR IOH TSO TRO PCUBO AVG SD SD ASD
1
2
LONG RANGE ENVIRONMENTAL PLANNING SIMULATOR PAGE 49

MICHIGAN STATE UNIVERSITY
DATE 09/05/70

LOCATION 1 IDENTIFICATION REPORT
QTR NO OF DUS S-M FACTOR DU WI SUM DOL SIZE IND

 

291

LONG RANGE ENVIRONMENTAL PLANNING SIMULATOR PAGE 50
MICHIGAN STATE UNIVERSITY
DATE 09/05/70

 

LOCATION l NORMAL ORDER CYCLE TIME DOLLAR PROPORTIONS
PROPORTION OF SALES DOLLARS WITHIN DAYS
QTR 3 5 7 9 ll
1
2
LONG RANGE ENVIRONMENTAL PLANNING SIMULATOR PAGE 51

MICHIGAN STATE UNIVERSITY
DATE 09/05/70

 

 

LOCATION 1 NORMAL ORDER CYCLE TIME ORDER PROPORTIONS
PROPORTION OF ORDERS WITHIN DAYS
QTR 3 5 7 9 11
1
2
LONG RANGE ENVIRONMENTAL PLANNING SIMULATOR PAGE 52

MICHIGAN STATE UNIVERSITY
DATE 09/05/70

 

LOCATION 1 WEIGHT CLASS ACCUMULATIONS IN THOUSANDS
QTR 0-50 51-200 201-1000 1001-UP
l
2
LONG RANGE ENVIRONMENTAL PLANNING SIMULATOR PAGE 53

MICHIGAN STATE UNIVERSITY
DATE 09/05/70

DC-MCC WEIGHT CLASS ACCUMULATIONS IN THOUSANDS FOR
LOCATION 1 FROM LOCATION 3
QTR 2M-5M 5M-24M 24M-UP
l
2

 

AVG

AVG SD

BO PEN
COM

DC

DOL SIZE IND
DU WI SUM
FAC

IBC

INV

INV OH
IOH

MCC

NO OF DUS
NOCT

OBC

OBT

OC TIME
PCUBO
PROFIT
QTR

S-M FACTOR
SD ASD

SD NOCT
SD OBT
TOT

TOT OCT
TPC

TRO

TSO

292

GLOSSARY OF ABBREVIATIONS

AVERAGE

AVERAGE STOCKOUT DELAY

BACK ORDER PENALTY TIME
COMMUNICATIONS COST
DISTRIBUTION CENTER

DOLLAR SIZE INDICATOR

SUM OF THE DU WEIGHTED INDICES
ALLOCATED FACILITIES COST: LAND, EQUIP
INBOUND SHIPPING COST
INVENTORY COST

AVG CUBIC INVENTORY ON HAND
AVG CUBIC INVENTORY ON HAND
MANUFACTURING CONTROL CENTER
NUMBER OF DEMAND UNITS

NORMAL ORDER CYCLE TIME
OUTBOUND SHIPPING COST
OUTBOUND TRANSIT TIME

ORDER CYCLE TIME

PERCENT CASE UNITS BACK ORDERED
SALES LESS DISTRIBUTION COST
QUARTER

SALES MODIFICATION FACTOR
STANDARD DEVIATION AVG SD
STANDARD DEVIATION NOCT
STANDARD DEVIATION OBT

TOTAL

TOTAL ORDER CYCLE TIME
THROUGHPUT COST

TOTAL REORDERS

TOTAL STOCKOUTS