WITNO05970109
WITN05970109
RESTRICTED - COMMERCIAL
PWY/JFO/005
POCL Infrastructure Demo - Meeting Report
Supplier: Pathway Date: 29 November 1995
Attendees:
BA/POCL Supplier
Jeremy Folkes Martyn Bennett (Risks - part)
Bob Booth Dave Cooke
Tony Hayward (Network - part)
Martin Johnston
David Shepherd (BT communications
management, partnered onto
ICL)
Bernard St Louis (BT Sys Engineer)
Roger Jones (pm - Riposte)
Dave Hollingsworth (pm - Riposte)
Martin McAdam (An Post - part)
Purpose:
Fifth “POCL Infrastructure” demonstrator meeting, concentrating on low volume Post
Offices and peripherals, BT ISDN and Riposte.
Items of Note:
1. Actions from last meeting:
« APPU loan - awaiting SP response to covering letter prior to its dispatch.
e Bar-codes, steer current requirement still 80mm 1-D. All comments on OCR and
cost differentials have been flagged to the programme. Still require a cost indication
of 110mm 1-D reader. SP is looking at Nippondenso that goes up to 100mm with
CCD, SP asked if can sub-equip, steer that this becomes a pain for customers and
only applicable for large offices - so small percentage saving - paper bills are not
regionally bound, and sub-equipping gives other problems.
¢ Back office impact printing. Repeated steer no current requirement, and believe that
such a requirement would be unlikely.
e Thermal printing - discussed, paper received (data from various manufacturers) -
different paper type have different characteristics. Looking at two part carbon BPS
slip for office printing, with pre-printed declarations (saving time and noise in the
office); storage thereafter may be easier than tally roll cut-offs - may use an Axiohm
thermal tally / impact slip - details passed over. Noted that tally roll for AP is used
for receipts, with APT having carbon, and ECCO having different clerk copy to assist
in re-keying.
« Dongles - still under design review. Question relates to how Pathway will maintain
strong identity and sequence numbering in the terminal. “No progress as Tony and
John Dicks have been away for the week, even though Mike Murphy brought this up
... believe that terminal identity may be better to be distributed centrally.” - Tony.
JF pointed out strong identity was the issue with monotonic sequencing and all we
were going was asking how they were going to meet Mike Murphy’s requirement -
and that he was suggesting dongle or banding on smart card. In Mike's phrase
“Pathway haven't got a clue” on this issue, and not only missed the point but started
Page 1 of 8
WITNO05970109
WITN05970109
RESTRICTED - COMMERCIAL
PWY/JFO/005
digging big holes and jumping in. They seem very sensitive to what Mike Murphy stated
earlier, Martin Johnson was getting fairly aggressive by the end of this.
Plug-in hard disk - decision extant, pricing decision versus risk. Current view is that
costing will be too high, but market is changing as media costs are dropping and
may become attractive. (£300-400 per PO for 10,000 PO’s, looking at the overall
cost, makes a high contribution). Single position office recovery to be addressed in
a brief paper (useful if other recovery / failure scenarios were covered) by 13/12.
Network Overview update due today - received.
Power fail closure conditions. Query still with requirements.
System management times etc. will be covered today.
. Low volume Post Offices and peripherals:
Explained the issue, that for a subset of outlets at the low end of transaction
volumes, a PC with n peripherals was not likely to be so acceptable, however, the
overall cost impact on the SP of providing a low end solution needs to be
understood. The POCL desire is for a common technology, interpreted to mean an
ability to perform the same functions throughout. As a minimum BA and AP (with
smart card) are the mandatory minimum. The ability for full EPOS (with cash
account etc.) may not be needed, especially for non-CA offices. Options sought.
Stressed that still a programme issue. This had been all explained in earlier discussions
but SP seemed only today to understand the drivers.
SP investigated Fortronic easy-pay systems etc. but view of that diverging from
universal solution was not thought viable. A reduced specification PC was preferred
though the main concern held by the SP was coping for subsequent needs to
upgrade this subset as requirements evolved, and being constrained by their low
end choice.
SP view that EPOS capture would not be a great overhead if BA and AP were being
captured, though A4 printing of cash account would be.
SP requested numbers of offices likely to be low-end. Steer that volume was largely
dependant on the SP solution, but likely key factors were: transaction level, range
of services offered, future-proof constraint the SP solution imposed.
It was recognised that a critical mass was required to make a divergence from the
universal solution viable in cost terms - absolute number may negate any options.
Steer that will be less than 5000 terminals affected was given, but a rider that this
would depend on SP solution, both function and cost. SP pointed out that notebook
+ extras in a photographers case may well be more expensive, though more
acceptable in terms of space and clutter.
If space is not an issue then cost cutting for lower volumes are SP has “thought
through”, possibly with same software but reduced function available.
JF explained that space was the key issue here, as was ease of set up in
community offices that would not have a permanent set up. In the past the Post
Office produced a Small Office Terminal (APT), with smart, magnetic, QWERTY etc.
as nothing was suitable in a single box with minimum wires. The market may now
have sufficiently changed for a standard offering to be suitable.
Paper to be produced taking the above on board 13/12. Pathway are employing a
firm of Swedish design consultants as input to the ergonomics/counter housing, and
this may be of use.
Page 2 of 8
RESTRICTED - COMMERCIAL
PWY/JFO/005
For a housing for the card peripherals, SP is looking to minimise keyboard use and
therefore its presence on the desk, and would look to provide a separate
magnetic/smart housing approach. Otherwise would incorporate on the keyboard an
ICL retail unit have a swipe/smart housing, detail handed out - see query re: ISO 7816.
« Eventual aim is to have a single unit with one cable.
3. BT ISDN-B:
e BT personnel were not ISDN experts, but wanted get questions and then take up
with relevant portions of BT.
« Closed User Group
Latest information on target for Spring 1997, and this is dictated by GPT
software release. BT ISDN product line tried to advance this without success,
largely down to the GPT commitments, and will be national available across all
exchange types (apparently not a problem with AXE-10 etc.)
Inter-work with other licensed operators - e.g. Hull - is an issue as BT have no
control over this, only OFTEL can push this. BT to respond.
Issue of CUG over an interconnect (between say BT and Mercury) is to be
clarified.
Outline of how it will operate is required, e.g. is it by line or centrally controlled.
Given the available date, at the start of rollout it will not be available and plans
for the migration to a CUG need to be covered, especially as it is a 24 hour
operation.
How churn is handled (for CUG changes) also needs documentation.
Number portability may come into this, along with presentation CLI, and how
further number changes will be handled.
e Presentation CLI
BT not aware of any cases of fraudulent CLI generation and logistics involved in
this make it, in BST opinion, unlikely.
Across an interconnect, could a BT CLI be presented in place of the
originators? Given the rise in the number of companies this may be an issue.
BT to respond.
There is a international standard User Provided Unscreened CLI (in ISDN) that
allows a user to generate a CLI, with a marker informing the called party that
the CLI was user generated. BT has no plans to introduce User Provided
Unscreened.
If Mercury offer this (presentation CLI different from real CLI), then BT would
probably also have to offer it, irrespective of their current marketing stance. BT
to respond.
OFTEL have a working group studying CLI, and one of their considerations is to
prevent fraud. This working group has not yet reported back. From visibility of
the Industry Presentation CLI working group, fraud is not high on their list of priorities
(this is one of the areas JF has been flagging with his TMA hat elsewhere!).
¢ ISDN service in rural areas:
Page 3 of 8
WITNO05970109
WITN05970109
WITNO05970109
WITN05970109
RESTRICTED - COMMERCIAL
PWY/JFO/005
e Currently BT ISDN is available to 98% UK businesses with ISDN. This is very
low, especially as a lot of the community / rural Post Offices will not be business
premises. ISDN-2 is normally within 5km of a service point, though trials are
scheduled for March 1996 to extend the reach, and if successful will increase
the standard limit to 10km of local exchange. Method by which this will be
achieved is not known, BT to update.
« Moving from IMUX to embedded line cards for System-X, with the IMUX being
re-deployed to other exchanges is believed to be one of the factors in
increasing range of ISDN.
e BT have a modelling tool based on grid-references, and this may take the
postal information of offices to determine coverage and “problem offices”.
e There are believed to be intermediate workarounds using IMUX’s, but BT keen
on knowing 5, 8, 10km rings, and would wish to leave furthest away until last if
possible to reduce their headaches and costs. Steer, liable to be other drivers
than just BT range of exchange - though Pathway need to feed this information
into the implementation strand. The drivers may be geographic demarcation
based on roll out of cards and as such an interim solution may be required.
e IMUX/Line card change at exchange does not impact the office (the new style
NTE-8 clamshell is apparently totally unrelated to the change to line cards).
This is at odds with statements from elsewhere in BT which link the change of NTE to
the change of exchange technology.
e Availability situation in Hull?
e LTE lock out
« No lock out as such, however there are in-built conditions, e.g. short circuit, B-
line to earth, so under local loop fault condition line is disconnected and will
need to be re-set.
e BT to check that faults are properly flagged. The scenario of a switched off PC
containing a card does should no longer cause a problem as the NTE-8 is
powered over the line and this is what the exchange talks to.
e Can get line-lock out if there are around 5 faults in an hour. BT will check exact
circumstances.
e ISDN-2 does not have pro-active monitoring, in event of fault condition the
customer will report the fault. Line lock-outs remain until customer reported. BT
to check.
¢ Does ISDN have BABT black list akin to modems?
* BT to check. And then how the host can contact it if tried several times without
success and is thus black-listed will be addressed if needed?
e Logistics, how can BT gear up for 20,000 lines.
e BT unclear exactly how roll out is intended, but is likely to base on National
Lottery experience, with dedicated teams on a regional basis. Seem to view
ALPS as the “how not to” experience.
e Do not anticipate a reduction in availability as move to line cards and longer lines,
and as availability is a regulated service no figures are available, but do have
successful call figures. JF to look up on his book case - recent BTEJ article.
e BT have figures for local loop for risk management but not to hand, and likely to be
very sensitive and speculative. BT record faults in Green and Red books.
Page 4 of 8
RESTRICTED - COMMERCIAL
PWY/JFO/005
Pathway are developing a “Call Management System” to handle the set-up of ISDN
calls - this seems to be a separate application, outwith Riposte. This is the subject
of a separate paper (requested).
. System Management paper:
Visibility on distribution of new release.
* Demonstration system is 6MB compressed, over ISDN is a 20 minute
download.
« ARiposte module, a typical compressed module 75K, 12 seconds
e Reference data 100K, 16 seconds
Would be downloading in advance with a flag acknowledging receipt and an
activation date. Would need to know, with number of lines proposed how long it
would take. If 720 ISDN lines, then the reference data example would be under an
hour, however the management / viability of hitting all the offices is the real issue,
uncompressing, disk space available ...
Free standing response required for risk 48 by 8/12, fax for 9 am to Bob.
. Riposte
Roger Jones gave out some supplementary notes which were then walked through.
The notes contained the caveat that these were based on his previous
understanding, and that he had not been able to check with Escher since last
meeting due to the Thanksgiving Holiday in the US. Demonstrates the reliance on
Escher in US.
Went over the failure in the walkthrough case in tedious detail (again) with Pathway
tripping over themselves, and Martin Johnson trying (badly) to show he understood
something. Pathway seemed keener to rubbish the specific example we had
come up with, rather than addressing the issue. Seemed to miss the point that
Mike Murphy had acknowledged it and did have an answer (using strong identity -
see earlier) but Pathway were unable to explain.
SP intimated that there may be an operational requirement for all PCs and the LAN
etc. to be up prior to re-starting a failed office, hopefully this kind of information will be
communicated rather than extracted.
Roger Jones guess that sufficient period set so data is not lost (not tied to business
events (see JM)). Need to remember that Riposte allows access to the
correspondence server so data may still be accessible in the office. Speak to
JM/Naresh about the application having access over the WAN to centrally held data, as the
impression is everything is held in the local journal file (with ancillary index files) so how
they bridge the WAN needs too be known.
An Post archiving will not be the same for Pathway, as An Post distributes encrypted
files containing payment data, whilst in BA/POCL Escher want to go back to using
message replication. Archiving - actually retention - seems to be constrained to be
longer than the life of the longest payment record (13 week life or 43 days,
whatever) as all records are sequenced numbered and can’t knock out messages in
the middle of a sequence. But “Mortality and inception are application specific"
(Roger Jones). All very confused.
Page 5 of 8
WITNO05970109
WITN05970109
WITNO05970109
WITN05970109
RESTRICTED - COMMERCIAL
PWY/JFO/005
Apparently An Post have a message per file in the log - we will have all payment
records in the file. Another potentially significant change.
If corruption is detected, then may just replace a corrupt record, but as only write to
the journal it is unclear how this could be achieved ? The problem of determining
which record is corrupt occurs as a journal has all the nodes data interspersed in
node sequence, but with random interleave of nodes. May just throw everything
away from just below the record and then re-synchronise, due to the perceived
infrequency, this approach may be the one Escher are taking. But Pathway are not
sure!
An Post have two correspondence servers (constrained by number of X.25 cards
that fit into a server rather than anything else) that partition the Post Offices between
them and replicate between themselves. Backup is done by a traditional backup
mechanism.
Currently An Post only has one group available to the correspondence server (Grof
0) which gives membership to all groups. Within BA/POCL each Post Office will be
a group, and at the correspondence server, the group will contain three
correspondence servers and all the office nodes.
Marker records have gone back to containing the tidemarks for all the nodes that a
machine is aware of.
Hierarchical indices and CRCs are new and for BA/POCL for performance based on
the size of the programme - 40,000 nodes all being replicated at the
correspondence server level.
There is a proposed re-design for two level markers for exchanging details between
the correspondence servers, and optimised to fit in a UDP packet. Between servers
the exchange will be of high level markers (CRC of a set of low level markers), and
as low level markers contribute to the high level markers if a change is detected, the
low level markers are then asked for, and then records that have changed as
indicated by the low level markers (these are at group level). As the high level
markers are a summary, they can exchange more frequently as less data is now
involved.
When reference data changes, a Persistent Journal Object is written into each
groups archive that it is to be distributed to at the correspondence layer, and these
journal entries are replicated out from the server in the normal Riposte manner.
Another BA/POCL enhancement under way is to have a higher level that can
logically write to all groups.
Had not thought of RDMS - have other SPs ? Steer that flat file will appear from “TIP”
and a box at the campus level would inject into Riposte, need to consider regional
portions as well.
Another extremely frustrating, contradictory day. Pathway seem afraid to admit that they
are changing Riposte. On one hand it is of concern as the changes reduce the value of
reference sites / track record, on the other it is good at showing they recognise that the
product is not perfect and may need changing for the higher volume environment that they
are proposing it for. However, the secretive and ill-informed attitude is damaging credibility
and amplifying our own doubts over the viability of the product.
. Reviewed Risk Register:
Risk 11 - Impact of keyboard/touch-screen on transaction times. Functional
Specification has given to Application team, showing screen shots and design
Page 6 of 8
WITNO05970109
WITN05970109
RESTRICTED - COMMERCIAL
PWY/JFO/005
approach, this was to have been passed on but due to level of change, Pathway
decided not to give us copy until version 2, due 5/12. Draft OPS menu strategy
handed over. JF to talk to JM - JM says he doubt if this document would help. Copy of
version 1 received by post from Pathway 1st Dec. anyway.
Risk 9 - Scalability and manageability. Discussed last week; paper extant, SP
happy that they can scale, we may downgrade from last weeks discussion to B1,
and it is hoped that the visit to Escher coupled with the paper should be able to clear
this. After the afternoon Riposte discussion any downgrade seems most unlikely.
Risk 48 - Distribution of software. Paper received last week, reviewed as part of this
meeting. Paper did not really address issues.
Risk 19 - Low volume equipment. Discuss today with peripherals. Risk remains,
though SP now has a better understanding of the background to the question.
Note: The risks were reviewed at the start of the meeting, however, due to time
constraints, they were not reviewed at the end of the meeting.
. Miscellaneous:
Offer of ECCO+ demo at Terminal House was mentioned during discussion on print
requirements at the counter. Dave Cooke seemed keen but Martin Johnson worried
about whether they'd have time! Bob to see if the ECCO file formats can be made
available in the demonstration room.
Steer that there is an interest in ability to incorporate CRISP into the SP solution
was now being expressed. This would require the control of a cash drawer by the
SP’s solution, and the standard EPOS stock ordering type information, which is
currently polled by a HP 3000 system (daily/weekly) that CRISP offers would need
to be available. There are a large number of primarily bar-coded items handled by
CRISP, and currently the CRISP units are treated as a single stock unit within the
office.
SP queried relationship with Riva. Steer that Riva won the contract to provide the
previous system and the Post Office is not believed to have ties to Riva for CRISP’s
replacement. Checked with Torstein afterwards, looks as if Riva may think they have
automatically got the replacement but this is not firm.
JF enquired if the OCR device that reads a standard font, and can read MICR (E13-
B) on cheques using the OCR facility. SP would need to investigate this but believe
their hardware will support this. SP to confirm.
Page 7 of 8
RESTRICTED - COMMERCIAL
Papers Received:
/2 and /3 with caveats).
Next meeting:
No meeting organised (site visits etc.), but outstanding issues are:
¢ Detailed changes inside Riposte 32 extant
e User administration
Riposte Scalability Risk Response
Call Management paper
Requirements Queries:
System Management/Downloading paper
PWY/JFO/005
“Riposte Architecture - supplementary notes” (Roger Jones, undated)
“The OPS menu strategy “ - Issue 0.1 dated 29/11/95 (draft)
“Thermal Paper Archival Life” - dated 28/11/95
“Network Overview” Version 2 dated 27/11/95
“Axiohm 7156 Receipt & Slip Point-of-Sale Printer” flimsy
“ICL Card Reader FCR20RS" flimsy (both magnetic and smart complying to 7816 /1,
Is the 110mm big enough to cope with the Steer, been looking at this, butis I Infra
variable length bar codes? an evolving standard with the
RECs. 110mm believed OK.
Receipt retention for AP (and others) within Steer, will depend on SP solution I Infra 1212
office and/or centrally. Period of retention and I asis currently used for recovery;
why? to determine what transactions go
to which client; possibly also for
legal reasons.
The proposed smart card reader appears to Believe the full ISO 7816-3 and -4 I Infra 12/12
offer only a fixed Sv programming voltage requires a programmable Vp
(Vp). Is this sufficient? Do we wish to force I (something like up to 25v in 0.1v
full compliance? steps). The existing GEMPLUS
GC1200 used in the APT gives
this. May be worth making
requirement explicit.
Pathway have asked at various times for Get examples of current pre- Warren/ I Bob to
samples of paper types / print types that need I printed forms to Pathway (with Dave chase
to be printed. Still not received. caveat that only examples). Thorne
Worked example requested for Giro print From kit at TH D Thorne I Bob to
outs? chase
Jeremy Folkes & Bob Booth 03/12/95
Page 8 of 8
WITNO05970109
WITNO05970109