BOSS

Nền tảng 8085 của chúng tôi không có hệ điều hành. Kinh nghiệm của tôi với hệ thống MPS của M365 và các cơ chế ngắt của IBM System 7 đã thuyết phục tôi rằng chúng tôi cần một bộ chuyển đổi tác vụ đơn giản cho 8085. Vì vậy, tôi đã hình thành nên BOSS: Basic Operating System and Scheduler[1].

Phần lớn BOSS được viết bằng C. Nó cung cấp khả năng tạo các nhiệm vụ đồng thời. Những nhiệm vụ đó không phải là nhiệm vụ ưu tiên — việc chuyển đổi nhiệm vụ không diễn ra dựa trên các ngắt. Thay vào đó, giống như với hệ thống MPS trên M365, các tác vụ được chuyển đổi dựa trên một cơ chế polling đơn giản. Việc polling diễn ra bất cứ khi nào một nhiệm vụ bị chặn bởi một sự kiện.

Lệnh gọi BOSS để khóa một nhiệm vụ trông như thế này:

block(eventCheckFunction);

Lệnh gọi này đã tạm ngừng tác vụ hiện tại, đặt eventCheckFunction vào danh sách polling và liên kết nó với tác vụ mới bị chặn. Sau đó, nó đợi trong vòng lặp polling, gọi từng hàm trong danh sách polling cho đến khi một trong số chúng trả về true. Tác vụ được liên kết với hàm đó sau đó sẽ được phép chạy.

Nói cách khác, như tôi đã nói trước đây, nó là một công cụ chuyển đổi tác vụ đơn giản.

Phần mềm này đã trở thành cơ sở cho rất nhiều dự án trong những năm sau đó. Một trong những dự án đầu tiên là pCCU.

pCCU

Cuối những năm 1970 và đầu những năm 1980 là thời kỳ hỗn loạn của các công ty điện thoại. Một trong những nguồn gốc của sự hỗn loạn đó là cuộc cách mạng kỹ thuật số.

Trong thế kỷ trước, kết nối giữa văn phòng chuyển mạch trung tâm và điện thoại của khách hàng là một cặp dây đồng. Những sợi dây này được bó lại thành những sợi cáp trải dài trong một mạng lưới khổng lồ khắp vùng nông thôn. Lúc thì chúng được treo trên cột, lúc thì chúng được chôn dưới đất.

Đồng là một kim loại quý, và công ty điện thoại đã có hàng tấn (nghĩa đen của hàng tấn) đồng phủ khắp đất nước. Vốn đầu tư này là rất khổng lồ. Phần lớn số vốn đó có thể được thu hồi bằng cách truyền tải cuộc trò chuyện điện thoại qua các kết nối kỹ thuật số. Một đôi dây đồng có thể thực hiện hàng trăm cuộc hội thoại ở dạng kỹ thuật số.

Để đáp lại, các công ty điện thoại đã bắt tay vào quá trình thay thế thiết bị chuyển mạch trung tâm cũ của họ bằng các thiết bị chuyển mạch kỹ thuật số hiện đại.

Sản phẩm 4-Tel của chúng tôi đã thử nghiệm dây đồng, không phải kết nối kỹ thuật số. Vẫn còn khá nhiều dây đồng trong môi trường kỹ thuật số, nhưng chúng ngắn hơn nhiều so với trước đây và chúng được địa phương hóa gần điện thoại của khách hàng. Tín hiệu sẽ được truyền kỹ thuật số từ văn phòng trung tâm đến điểm phân phối cục bộ, nơi mà nó sẽ được chuyển đổi trở lại thành tín hiệu analog và phân phối tới khách hàng qua dây đồng tiêu chuẩn. Điều này có nghĩa là thiết bị đo lường của chúng tôi cần phải được đặt ở nơi bắt đầu các dây đồng, nhưng thiết bị quay số của chúng tôi cần phải ở văn phòng trung tâm. Vấn đề là tất cả các COLT của chúng tôi đều thể hiện cả tính năng quay số và đo lường trong cùng một thiết bị. (Chúng tôi có thể đã tiết kiệm cho mình một gia tài nếu chúng tôi nhận ra ranh giới kiến ​​trúc rõ ràng đó một vài năm trước đó!)

Do đó, chúng tôi đã hình thành một kiến ​​trúc sản phẩm mới: CCU / CMU (bộ điều khiển COLT và bộ đo lường COLT). CCU sẽ được đặt tại văn phòng chuyển mạch trung tâm và sẽ xử lý việc quay số của các đường dây điện thoại sẽ được kiểm tra. CMU sẽ được đặt tại các điểm phân phối địa phương và sẽ đo các dây đồng dẫn đến điện thoại của khách hàng.

Vấn đề là đối với mỗi CCU, có nhiều CMU. Thông tin về CMU nào sẽ được sử dụng cho mỗi số điện thoại do chính bộ chuyển mạch kỹ thuật số nắm giữ. Do đó CCU đã phải truy vấn bộ chuyển mạch kỹ thuật số để xác định CMU nào cần giao tiếp và điều khiển.

Chúng tôi đã hứa với các công ty điện thoại rằng chúng tôi sẽ làm kiến trúc mới này hoạt động kịp thời cho quá trình chuyển đổi của họ. Chúng tôi biết là chúng phải mất vài tháng, nếu không muốn nói là nhiều năm, vì vậy chúng tôi không cảm thấy vội vã. Chúng tôi cũng biết rằng sẽ mất vài năm nhân lực để phát triển phần cứng và phần mềm CCU / CMU mới này.

Bẫy lịch trình

Theo thời gian, chúng tôi nhận thấy rằng luôn có những vấn đề cấp bách buộc chúng tôi phải trì hoãn việc phát triển kiến ​​trúc CCU/CMU. Chúng tôi cảm thấy an toàn về quyết định này bởi vì các công ty điện thoại khác cũng liên tục trì hoãn việc triển khai các bộ chuyển mạch kỹ thuật số. Khi xem lịch trình của họ, chúng tôi cảm thấy tự tin rằng mình còn nhiều thời gian, vì vậy chúng tôi đã liên tục trì hoãn sự phát triển của mình.

Rồi đến một ngày sếp của tôi gọi tôi vào văn phòng của ông ấy và nói: “Một trong những khách hàng của chúng ta đang triển khai bộ chuyển mạch kỹ thuật số vào tháng tới. Đến lúc đó chúng ta phải có CCU/CMU hoạt động. ”

Tôi đã rất kinh hoàng! Làm thế nào chúng ta có thể đạt được số năm phát triển của con người trong một tháng? Nhưng sếp của tôi đã có một kế hoạch …

Trên thực tế, chúng tôi không cần một kiến ​​trúc CCU/CMU đầy đủ. Công ty điện thoại đang triển khai bộ chuyển mạch kỹ thuật số này rất nhỏ. Họ chỉ có một văn phòng trung tâm và chỉ có hai điểm phân phối tại địa phương. Quan trọng hơn, các điểm phân phối “địa phương” không phải đúng là địa phương. Họ thực ra có các thiết bị chuyển mạch analog cũ bình thường chuyển mạch cho hàng trăm khách hàng. Tốt hơn nữa, những bộ chuyển mạch đó thuộc loại có thể quay số bằng COLT bình thường. Thậm chí tốt hơn nữa, số điện thoại của khách hàng chứa tất cả thông tin cần thiết để quyết định sử dụng điểm phân phối cục bộ nào. Nếu số điện thoại có 5, 6 hoặc 7 ở một vị trí nhất định, nó sẽ chuyển đến điểm phân phối 1; nếu không, nó đã đi đến điểm phân phối 2.

Vì vậy, như sếp của tôi đã giải thích với tôi, chúng tôi thực sự không cần CCU/CMU. Những gì chúng tôi cần là một máy tính đơn giản tại văn phòng trung tâm được kết nối bằng đường dây modem với hai COLT tiêu chuẩn tại các điểm phân phối. SAC sẽ giao tiếp với máy tính của chúng tôi tại văn phòng trung tâm và máy tính đó sẽ giải mã số điện thoại và sau đó chuyển tiếp các lệnh quay số và đo lường tới COLT tại điểm phân phối thích hợp.

Do đó, pCCU đã được sinh ra.

Đây là sản phẩm đầu tiên được viết bằng C và sử dụng BOSS đã được triển khai cho khách hàng. Tôi mất khoảng một tuần để phát triển. Câu chuyện này không có ý nghĩa kiến ​​trúc sâu sắc, nhưng nó tạo nên một lời mở đầu đẹp cho dự án tiếp theo.

DLU/DRU

Vào đầu những năm 1980, một trong những khách hàng của chúng tôi là một công ty điện thoại ở Texas. Họ bao phủ một khu vực địa lý rộng lớn. Trên thực tế, các khu vực đó rộng lớn đến mức mỗi một khu vực dịch vụ cần có nhiều văn phòng khác nhau để điều phối thợ. Những văn phòng đó có những người thợ kiểm tra, những người cần thiết bị đầu cuối vào SAC của chúng tôi.

Bạn có thể nghĩ rằng đây là một vấn đề đơn giản để giải quyết – nhưng hãy nhớ rằng câu chuyện này diễn ra vào đầu những năm 1980. Thiết bị đầu cuối từ xa không phổ biến lắm. Để làm cho vấn đề tồi tệ hơn, phần cứng của SAC cho rằng tất cả các thiết bị đầu cuối đều là cục bộ. Các thiết bị đầu cuối của chúng tôi thực sự nằm trên một bus nối tiếp, tốc độ cao, được phát triển riêng.

Chúng tôi có khả năng truy cập thiết bị đầu cuối từ xa, nhưng nó dựa trên modem và vào đầu những năm 1980, modem thường bị giới hạn ở tốc độ 300 bit mỗi giây. Khách hàng của chúng tôi không hài lòng với tốc độ chậm chạp đó.

Thời đó đã bắt đầu có modem tốc độ cao, nhưng chúng rất đắt và chúng cần phải chạy trên các kết nối cố định “có điều kiện”. Chất lượng kết nối quay số chắc chắn là không đủ tốt.

Khách hàng của chúng tôi yêu cầu một giải pháp. Câu trả lời của chúng tôi là DLU/DRU.

DLU/DRU là viết tắt của “Bộ Hiển Thị Cục Bộ” (Display Local Unit) và “Bộ Hiển Thị Từ Xa” (Display Remote Unit). DLU là một bảng mạch máy tính cắm vào khung máy tính SAC và mô phỏng là một bảng quản lý thiết bị đầu cuối. Tuy nhiên, thay vì điều khiển bus nối tiếp cho các thiết bị đầu cuối cục bộ, nó đã lấy luồng ký tự và ghép nó qua một kết nối modem có điều kiện 9600-bps.

DRU là một hộp được đặt ở vị trí của khách hàng ở xa. Nó kết nối với đầu kia của kết nối 9600-bps và có phần cứng để điều khiển các thiết bị đầu cuối trên bus nối tiếp độc quyền của chúng tôi. Nó phân kênh các ký tự nhận được từ liên kết 9600-bps và gửi chúng đến các thiết bị đầu cuối cục bộ thích hợp.

Thật kỳ lạ, phải không? Chúng tôi đã phải thiết kế một giải pháp mà ngày nay đã phổ biến đến mức chúng tôi thậm chí không bao giờ nghĩ đến nó. Nhưng hồi đó …

Chúng tôi thậm chí đã phải phát minh ra giao thức truyền thông của riêng mình bởi vì, trong những ngày đó, các giao thức truyền thông tiêu chuẩn không phải là dạng phần mềm chia sẻ mã nguồn mở. Quả thực, đây là thời điểm rất lâu trước khi chúng ta có bất kỳ loại kết nối Internet nào.

Kiến trúc

Kiến trúc của hệ thống này rất đơn giản, nhưng có một số điểm kỳ quặc thú vị mà tôi muốn nhấn mạnh. Đầu tiên, cả hai thiết bị này đều sử dụng công nghệ 8085 của chúng tôi và cả hai đều được viết bằng C và sử dụng BOSS. Nhưng đó là những điểm tương đồng duy nhất.

Dự án đó có hai người. Tôi là trưởng dự án, và Mike Carew là cộng sự thân thiết của tôi. Tôi đảm nhận việc thiết kế và viết mã của DLU; Mike đã thực hiện DRU.

Kiến trúc của DLU dựa trên mô hình luồng dữ liệu. Mỗi tác vụ thực hiện một công việc nhỏ và tập trung, sau đó chuyển đầu ra của nó cho tác vụ tiếp theo trong hàng, sử dụng một hàng đợi. Hãy nghĩ về mô hình pipe và bộ lọc trong UNIX. Kiến trúc này rất rắc rối. Một nhiệm vụ có thể cung cấp một hàng đợi mà nhiều tác vụ khác sẽ phục vụ. Các tác vụ khác sẽ cung cấp một hàng đợi mà chỉ một tác vụ sẽ phục vụ.

Hãy nghĩ về một dây chuyền lắp ráp. Mỗi vị trí trên dây chuyền lắp ráp đều có một công việc duy nhất, đơn giản, tập trung cao độ để thực hiện. Sau đó, sản phẩm di chuyển đến vị trí tiếp theo trong hàng. Đôi khi dây chuyền lắp ráp chia thành nhiều dây chuyền. Đôi khi những dòng này hợp nhất lại thành một dòng. Đó là DLU.

DRU của Mike đã sử dụng một sơ đồ hoàn toàn khác. Anh ấy đã tạo một nhiệm vụ cho mỗi thiết bị đầu cuối và chỉ cần thực hiện toàn bộ công việc cho thiết bị đầu cuối đó trong nhiệm vụ đó. Không có hàng đợi. Không có luồng dữ liệu. Chỉ là nhiều nhiệm vụ lớn giống hệt nhau, mỗi tác vụ quản lý thiết bị đầu cuối của riêng mình.

Điều này ngược lại với một dây chuyền lắp ráp. Trong trường hợp này, cũng tương tự như có nhiều chuyên gia xây dựng, mỗi người trong số họ lại xây dựng toàn bộ sản phẩm của mình.

Vào thời điểm đó, tôi nghĩ rằng kiến ​​trúc của tôi là vượt trội. Với Mike thì tất nhiên, nghĩ rằng anh ấy tốt hơn. Chúng tôi đã có nhiều cuộc thảo luận thú vị về điều này. Cuối cùng, tất nhiên, cả hai đều hoạt động khá tốt. Và tôi nhận ra rằng các kiến ​​trúc phần mềm có thể rất khác biệt, nhưng vẫn có hiệu quả như nhau.

VRS

Khi những năm 1980 tiến triển, các công nghệ ngày càng mới hơn đã xuất hiện. Một trong những công nghệ đó là máy tính điều khiển bằng giọng nói.

Một trong những tính năng của hệ thống 4-Tel là khả năng xác định vị trí lỗi trong cáp của người thợ. Thủ tục thực hiện như sau:

• Người kiểm tra, tại văn phòng trung tâm, sẽ sử dụng hệ thống của chúng tôi để xác định khoảng cách gần đúng, tính bằng feet, tới lỗi. Điều này sẽ chính xác trong khoảng 20% ​. Người kiểm tra sẽ cử một thợ sửa chữa cáp đến một điểm truy cập thích hợp gần vị trí đó.

• Khi đến nơi, thợ sửa chữa cáp sẽ gọi cho người kiểm tra và yêu cầu bắt đầu quá trình xác định vị trí lỗi. Người kiểm tra sẽ gọi tính năng định vị lỗi của hệ thống 4-Tel. Hệ thống sẽ bắt đầu đo các đặc tính điện của đường dây bị lỗi đó và sẽ in thông báo trên màn hình yêu cầu thực hiện một số thao tác nhất định, chẳng hạn như mở cáp hoặc đoản mạch cáp.

• Người kiểm tra sẽ cho thợ sửa chữa biết hệ thống muốn vận hành như thế nào nào và người thợ sửa chữa sẽ cho người kiểm tra biết sau khi hành động hoàn tất. Sau đó, người kiểm tra sẽ thông báo cho hệ thống biết rằng hành động đã hoàn thành và hệ thống sẽ tiếp tục kiểm tra.

• Sau hai hoặc ba lần tương tác như vậy, hệ thống sẽ tính toán khoảng cách mới đến lỗi. Sau đó, người thợ cáp sẽ lái xe đến vị trí đó và bắt đầu lại quy trình.

Hãy tưởng tượng điều đó sẽ tốt hơn bao nhiêu nếu những người thợ sửa chữa cáp, đang ở trên cột hoặc đứng ở bệ, có thể tự vận hành hệ thống. Và đó chính xác là những gì công nghệ giọng nói mới cho phép chúng tôi làm. Các thợ sửa cáp có thể gọi trực tiếp vào hệ thống của chúng tôi, điều khiển hệ thống bằng cảm biến âm thanh và lắng nghe kết quả được đọc lại cho họ bằng một giọng nói dễ chịu.

Cái tên

Công ty tôi đã tổ chức một cuộc thi nhỏ để chọn một cái tên cho hệ thống mới. Một trong những cái tên sáng tạo nhất được gợi ý là SAM CARP. Nó có nghĩa là “Still Another Manifestation of Capitalist Avarice Repressing the Proletariat” (Vẫn Còn Một Biểu Hiện Khác Của Sự Bạo Ngược Của Tư Bản Đàn Áp Giai Cấp Vô Sản). Không cần phải nói nhiều, cái tên đó đã không được chọn.

Một cái tên khác là Teradyne Interactive Test System (Hệ thống Kiểm tra Tương tác Teradyne). Cái đó cũng không được chọn.

Vẫn còn một cái tên khác là Service Area Test Access Network (Mạng Truy Cập Kiểm Tra Khu Vực Dịch vụ). Nó cũng không được chọn.

Cuối cùng, cái tên thắng cuộc là VRS: Voice Response System (Hệ Thống Phản Hồi Bằng Giọng Nói).

Kiến trúc

Tôi không làm việc với hệ thống này, nhưng tôi đã nghe về những gì đã xảy ra. Câu chuyện tôi sắp kể với bạn là một câu chuyện truyền miệng, nhưng phần lớn, tôi tin nó là chính xác.

Đó là những ngày đầu tiên của máy vi tính, hệ điều hành UNIX, ngôn ngữ C và cơ sở dữ liệu SQL. Chúng tôi đã quyết tâm sử dụng tất cả những công nghệ đó.

Từ rất nhiều nhà cung cấp cơ sở dữ liệu, cuối cùng chúng tôi đã chọn UNIFY. UNIFY là một hệ thống cơ sở dữ liệu hoạt động với UNIX, hệ thống này hoàn hảo đối với chúng tôi.

UNIFY hỗ trợ một công nghệ mới được gọi là Embedded SQL. Công nghệ này cho phép chúng tôi nhúng các lệnh SQL, dưới dạng chuỗi, ngay vào mã C của chúng tôi. Và vì vậy, chúng tôi đã làm điều đó – ở khắp mọi nơi.

Ý tôi là, nó thật tuyệt khi bạn có thể đưa ngay SQL vào mã của mình, ở bất cứ đâu bạn muốn. Và chúng tôi muốn ở đâu? Mọi nơi! Và do đó, các lệnh SQL đã bị bôi ra khắp phần thân code đó.

Tất nhiên, trong những ngày đó, SQL không phải là một tiêu chuẩn vững chắc. Có rất nhiều cú pháp SQL đặc biệt dành riêng cho từng nhà cung cấp. Vì vậy, các lệnh gọi SQL đặc biệt và các lệnh gọi API UNIFY đặc biệt cũng bị bôi ra trong toàn bộ mã.

Những thứ này hoạt động tuyệt vời! Hệ thống đã thành công. Các thợ sửa chữa đã sử dụng nó, và các công ty điện thoại yêu thích nó. Cuộc sống toàn là những nụ cười hạnh phúc.

Sau đó sản phẩm UNIFY chúng tôi đang sử dụng đã bị hủy bỏ.

Ố. Ồ.

Vì vậy, chúng tôi quyết định chuyển sang SyBase. Hay đó là Ingress gì đó? Tôi không nhớ rõ. Chỉ cần nói rằng, chúng tôi đã phải tìm kiểm qua tất cả code C đó, tìm tất cả các lệnh gọi API đặc biệt và SQL được nhúng và thay thế chúng bằng các chức năng tương ứng của nhà cung cấp mới.

Sau ba tháng nỗ lực, chúng tôi đã bỏ cuộc. Chúng tôi không thể làm cho nó hoạt động. Chúng tôi đã bị gắn kết chặt với UNIFY đến nỗi không còn hy vọng gì về việc tái cấu trúc lại chỗ code này với bất cứ chi phí khả thi nào.

Vì vậy, chúng tôi đã thuê một bên thứ ba để duy trì UNIFY cho chúng tôi, dựa trên hợp đồng bảo trì. Và, tất nhiên, phí bảo trì tăng lên từ năm này qua năm khác.

Kết luận VRS

Đây là một trong những cách mà tôi đã học được rằng cơ sở dữ liệu là chi tiết nên được tách biệt khỏi mục đích nghiệp vụ tổng thể của hệ thống. Đây cũng là một trong những lý do mà tôi không thích gắn kết chặt chẽ với các hệ thống phần mềm của bên thứ ba.

---

[1] Phần mềm này sau đó được đổi tên thành Bob’s Only Successful Software – Phần mềm thành công duy nhất của Bob.