ಪ್ರೋಗ್ರಾಮರ್‌ಗಳು ಮತ್ತು ಇಂಜಿನಿಯರ್‌ಗಳ ಜಾನಪದ (ಭಾಗ 1)

ದೋಷಗಳು ಕೆಲವೊಮ್ಮೆ ಸಂಪೂರ್ಣವಾಗಿ ನಂಬಲಾಗದ ಅಭಿವ್ಯಕ್ತಿಗಳನ್ನು ಹೇಗೆ ಹೊಂದಿವೆ ಎಂಬುದರ ಕುರಿತು ಇದು ಇಂಟರ್ನೆಟ್‌ನಿಂದ ಕಥೆಗಳ ಆಯ್ಕೆಯಾಗಿದೆ. ಬಹುಶಃ ನಿಮಗೂ ಹೇಳಲು ಏನಾದರೂ ಇದೆ.

ವೆನಿಲ್ಲಾ ಐಸ್ ಕ್ರೀಂಗೆ ಕಾರ್ ಅಲರ್ಜಿ

ಸ್ಪಷ್ಟವಾದವು ಯಾವಾಗಲೂ ಉತ್ತರವಲ್ಲ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಎಂಜಿನಿಯರ್‌ಗಳಿಗೆ ಒಂದು ಕಥೆ, ಮತ್ತು ಸತ್ಯಗಳು ಎಷ್ಟೇ ದೂರವಾದವು ಎಂದು ತೋರುತ್ತದೆಯಾದರೂ, ಅವು ಇನ್ನೂ ಸತ್ಯಗಳಾಗಿವೆ. ಜನರಲ್ ಮೋಟಾರ್ಸ್ ಕಾರ್ಪೊರೇಶನ್‌ನ ಪಾಂಟಿಯಾಕ್ ವಿಭಾಗವು ದೂರು ಸ್ವೀಕರಿಸಿದೆ:

ನಾನು ನಿಮಗೆ ಎರಡನೇ ಬಾರಿಗೆ ಬರೆಯುತ್ತಿದ್ದೇನೆ ಮತ್ತು ಉತ್ತರಿಸದಿದ್ದಕ್ಕಾಗಿ ನಾನು ನಿಮ್ಮನ್ನು ದೂಷಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಅದು ಹುಚ್ಚನಂತೆ ತೋರುತ್ತದೆ. ರಾತ್ರಿ ಊಟವಾದ ನಂತರ ಐಸ್ ಕ್ರೀಮ್ ತಿನ್ನುವ ಸಂಪ್ರದಾಯ ನಮ್ಮ ಕುಟುಂಬದಲ್ಲಿದೆ. ಐಸ್ ಕ್ರೀಂನ ಪ್ರಕಾರಗಳು ಪ್ರತಿ ಬಾರಿಯೂ ಬದಲಾಗುತ್ತವೆ, ಮತ್ತು ರಾತ್ರಿಯ ಊಟದ ನಂತರ, ಇಡೀ ಕುಟುಂಬವು ಯಾವ ಐಸ್ ಕ್ರೀಮ್ ಅನ್ನು ಖರೀದಿಸಬೇಕೆಂದು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಅದರ ನಂತರ ನಾನು ಅಂಗಡಿಗೆ ಹೋಗುತ್ತೇನೆ. ನಾನು ಇತ್ತೀಚೆಗೆ ಹೊಸ ಪಾಂಟಿಯಾಕ್ ಅನ್ನು ಖರೀದಿಸಿದೆ ಮತ್ತು ಅಂದಿನಿಂದ ಐಸ್ ಕ್ರೀಮ್ ಪಡೆಯಲು ನನ್ನ ಪ್ರವಾಸಗಳು ಸಮಸ್ಯೆಯಾಗಿವೆ. ನೀವು ನೋಡಿ, ನಾನು ವೆನಿಲ್ಲಾ ಐಸ್ ಕ್ರೀಮ್ ಖರೀದಿಸಿ ಅಂಗಡಿಯಿಂದ ಹಿಂತಿರುಗಿದಾಗ, ಕಾರು ಸ್ಟಾರ್ಟ್ ಆಗುವುದಿಲ್ಲ. ನಾನು ಬೇರೆ ಐಸ್ ಕ್ರೀಮ್ ತಂದರೆ, ಯಾವುದೇ ತೊಂದರೆಯಿಲ್ಲದೆ ಕಾರು ಸ್ಟಾರ್ಟ್ ಆಗುತ್ತದೆ. ನಾನು ಗಂಭೀರವಾದ ಪ್ರಶ್ನೆಯನ್ನು ಕೇಳಲು ಬಯಸುತ್ತೇನೆ, ಅದು ಎಷ್ಟೇ ಮೂರ್ಖ ಎನಿಸಿದರೂ: "ನಾನು ವೆನಿಲ್ಲಾ ಐಸ್ ಕ್ರೀಮ್ ಅನ್ನು ತಂದಾಗ ಅದು ಪ್ರಾರಂಭವಾಗುವುದಿಲ್ಲ, ಆದರೆ ನಾನು ಐಸ್ ಕ್ರೀಂನ ಮತ್ತೊಂದು ಪರಿಮಳವನ್ನು ತಂದಾಗ ಅದು ಸುಲಭವಾಗಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ?" "

ನೀವು ಊಹಿಸುವಂತೆ, ವಿಭಾಗದ ಅಧ್ಯಕ್ಷರು ಪತ್ರದ ಬಗ್ಗೆ ಸಂಶಯ ವ್ಯಕ್ತಪಡಿಸಿದ್ದಾರೆ. ಹೇಗಾದರೂ, ಒಂದು ಸಂದರ್ಭದಲ್ಲಿ, ನಾನು ಪರಿಶೀಲಿಸಲು ಎಂಜಿನಿಯರ್ ಕಳುಹಿಸಲಾಗಿದೆ. ಸುಂದರವಾದ ಪ್ರದೇಶದಲ್ಲಿ ವಾಸಿಸುವ ಶ್ರೀಮಂತ, ಸುಶಿಕ್ಷಿತ ವ್ಯಕ್ತಿಯೊಬ್ಬರು ಅವರನ್ನು ಭೇಟಿಯಾದರು ಎಂದು ಅವರು ಆಶ್ಚರ್ಯಚಕಿತರಾದರು. ಇಬ್ಬರೂ ಐಸ್ ಕ್ರೀಂಗಾಗಿ ಅಂಗಡಿಗೆ ಹೋಗಬಹುದು ಎಂದು ಅವರು ರಾತ್ರಿ ಊಟವಾದ ತಕ್ಷಣ ಭೇಟಿಯಾಗಲು ಒಪ್ಪಿಕೊಂಡರು. ಆ ಸಂಜೆ ಅದು ವೆನಿಲ್ಲಾ ಆಗಿತ್ತು, ಮತ್ತು ಅವರು ಕಾರಿಗೆ ಹಿಂತಿರುಗಿದಾಗ ಅದು ಸ್ಟಾರ್ಟ್ ಆಗಲಿಲ್ಲ.

ಇಂಜಿನಿಯರ್ ಇನ್ನೂ ಮೂರು ಸಂಜೆ ಬಂದರು. ಮೊದಲ ಬಾರಿಗೆ ಐಸ್ ಕ್ರೀಮ್ ಚಾಕೊಲೇಟ್ ಆಗಿತ್ತು. ಕಾರು ಸ್ಟಾರ್ಟ್ ಆಯಿತು. ಎರಡನೇ ಬಾರಿಗೆ ಸ್ಟ್ರಾಬೆರಿ ಐಸ್ ಕ್ರೀಮ್ ಇತ್ತು. ಕಾರು ಸ್ಟಾರ್ಟ್ ಆಯಿತು. ಮೂರನೇ ಸಂಜೆ ಅವರು ವೆನಿಲ್ಲಾ ತೆಗೆದುಕೊಳ್ಳಲು ಹೇಳಿದರು. ಕಾರು ಸ್ಟಾರ್ಟ್ ಆಗಲಿಲ್ಲ.

ತರ್ಕಬದ್ಧವಾಗಿ ತಾರ್ಕಿಕವಾಗಿ, ಇಂಜಿನಿಯರ್ ಕಾರಿಗೆ ವೆನಿಲ್ಲಾ ಐಸ್ ಕ್ರೀಮ್ಗೆ ಅಲರ್ಜಿ ಇದೆ ಎಂದು ನಂಬಲು ನಿರಾಕರಿಸಿದರು. ಆದ್ದರಿಂದ, ಸಮಸ್ಯೆಗೆ ಪರಿಹಾರವನ್ನು ಕಂಡುಕೊಳ್ಳುವವರೆಗೆ ಅವರ ಭೇಟಿಯನ್ನು ಮುಂದುವರಿಸುವುದಾಗಿ ನಾನು ಕಾರಿನ ಮಾಲೀಕರೊಂದಿಗೆ ಒಪ್ಪಿಕೊಂಡೆ. ಮತ್ತು ದಾರಿಯುದ್ದಕ್ಕೂ, ಅವರು ಟಿಪ್ಪಣಿಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಿದರು: ಅವರು ಎಲ್ಲಾ ಮಾಹಿತಿ, ದಿನದ ಸಮಯ, ಗ್ಯಾಸೋಲಿನ್ ಪ್ರಕಾರ, ಆಗಮನದ ಸಮಯ ಮತ್ತು ಅಂಗಡಿಯಿಂದ ಹಿಂತಿರುಗುವ ಸಮಯ ಇತ್ಯಾದಿಗಳನ್ನು ಬರೆದರು.

ಕಾರಿನ ಮಾಲೀಕರು ವೆನಿಲ್ಲಾ ಐಸ್ ಕ್ರೀಮ್ ಖರೀದಿಸಲು ಕಡಿಮೆ ಸಮಯವನ್ನು ಕಳೆದರು ಎಂದು ಎಂಜಿನಿಯರ್ ಶೀಘ್ರದಲ್ಲೇ ಅರಿತುಕೊಂಡರು. ಕಾರಣ ಅಂಗಡಿಯಲ್ಲಿನ ಸರಕುಗಳ ವಿನ್ಯಾಸವಾಗಿತ್ತು. ವೆನಿಲ್ಲಾ ಐಸ್ ಕ್ರೀಮ್ ಅತ್ಯಂತ ಜನಪ್ರಿಯವಾಗಿತ್ತು ಮತ್ತು ಅದನ್ನು ಹುಡುಕಲು ಸುಲಭವಾಗುವಂತೆ ಅಂಗಡಿಯ ಮುಂಭಾಗದಲ್ಲಿ ಪ್ರತ್ಯೇಕ ಫ್ರೀಜರ್‌ನಲ್ಲಿ ಇರಿಸಲಾಗಿತ್ತು. ಮತ್ತು ಎಲ್ಲಾ ಇತರ ಪ್ರಭೇದಗಳು ಅಂಗಡಿಯ ಹಿಂಭಾಗದಲ್ಲಿವೆ, ಮತ್ತು ಸರಿಯಾದ ವೈವಿಧ್ಯತೆಯನ್ನು ಕಂಡುಹಿಡಿಯಲು ಮತ್ತು ಪಾವತಿಸಲು ಇದು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಂಡಿತು.

ಈಗ ಇಂಜಿನಿಯರ್‌ಗೆ ಪ್ರಶ್ನೆ: ಇಂಜಿನ್ ಆಫ್ ಮಾಡಿದ ಕ್ಷಣದಿಂದ ಕಡಿಮೆ ಸಮಯ ಕಳೆದಿದ್ದರೆ ಕಾರು ಏಕೆ ಪ್ರಾರಂಭಿಸಲಿಲ್ಲ? ಸಮಸ್ಯೆಯು ಸಮಯವಾಗಿರುವುದರಿಂದ, ವೆನಿಲ್ಲಾ ಐಸ್ ಕ್ರೀಮ್ ಅಲ್ಲ, ಎಂಜಿನಿಯರ್ ತ್ವರಿತವಾಗಿ ಉತ್ತರವನ್ನು ಕಂಡುಕೊಂಡರು: ಅದು ಗ್ಯಾಸ್ ಲಾಕ್ ಆಗಿತ್ತು. ಇದು ಪ್ರತಿ ಸಂಜೆ ಸಂಭವಿಸಿತು, ಆದರೆ ಕಾರ್ ಮಾಲೀಕರು ಐಸ್ ಕ್ರೀಮ್ಗಾಗಿ ಹೆಚ್ಚು ಸಮಯವನ್ನು ಕಳೆದಾಗ, ಎಂಜಿನ್ ಸಾಕಷ್ಟು ತಂಪಾಗಿಸಲು ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಸುಲಭವಾಗಿ ಪ್ರಾರಂಭವಾಯಿತು. ಮತ್ತು ಮನುಷ್ಯನು ವೆನಿಲ್ಲಾ ಐಸ್ಕ್ರೀಮ್ ಅನ್ನು ಖರೀದಿಸಿದಾಗ, ಎಂಜಿನ್ ಇನ್ನೂ ತುಂಬಾ ಬಿಸಿಯಾಗಿತ್ತು ಮತ್ತು ಗ್ಯಾಸ್ ಲಾಕ್ ಅನ್ನು ಕರಗಿಸಲು ಸಮಯವಿರಲಿಲ್ಲ.

ನೈತಿಕ: ಸಂಪೂರ್ಣವಾಗಿ ಕ್ರೇಜಿ ಸಮಸ್ಯೆಗಳು ಕೆಲವೊಮ್ಮೆ ನಿಜ.

ಕ್ರಾಶ್ ಪ್ರಾಣಿಗಳಲ್ಲಿ

ಇದನ್ನು ಅನುಭವಿಸುವುದು ನೋವಿನ ಸಂಗತಿ. ಪ್ರೋಗ್ರಾಮರ್ ಆಗಿ, ನಿಮ್ಮ ಕೋಡ್ ಅನ್ನು ಮೊದಲು, ಎರಡನೇ, ಮೂರನೇ... ಮತ್ತು ಎಲ್ಲೋ ಹತ್ತು ಸಾವಿರದ ಸ್ಥಳದಲ್ಲಿ ನೀವು ಕಂಪೈಲರ್ ಅನ್ನು ದೂಷಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ. ಮತ್ತು ಪಟ್ಟಿಯ ಕೆಳಗೆ ನೀವು ಈಗಾಗಲೇ ಉಪಕರಣವನ್ನು ದೂಷಿಸುತ್ತೀರಿ.

ಹಾರ್ಡ್‌ವೇರ್ ದೋಷದ ಬಗ್ಗೆ ನನ್ನ ಕಥೆ ಇಲ್ಲಿದೆ.

ಕ್ರ್ಯಾಶ್ ಬ್ಯಾಂಡಿಕೂಟ್ ಆಟಕ್ಕಾಗಿ, ಮೆಮೊರಿ ಕಾರ್ಡ್‌ಗೆ ಲೋಡ್ ಮಾಡಲು ಮತ್ತು ಉಳಿಸಲು ನಾನು ಕೋಡ್ ಅನ್ನು ಬರೆದಿದ್ದೇನೆ. ಅಂತಹ ಸ್ಮಗ್ ಗೇಮ್ ಡೆವಲಪರ್‌ಗೆ, ಇದು ಉದ್ಯಾನದಲ್ಲಿ ನಡೆದಾಡುವಂತಿದೆ: ಕೆಲಸವು ಹಲವಾರು ದಿನಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸಿದೆ. ಆದಾಗ್ಯೂ, ನಾನು ಆರು ವಾರಗಳವರೆಗೆ ಕೋಡ್ ಅನ್ನು ಡೀಬಗ್ ಮಾಡುವುದನ್ನು ಕೊನೆಗೊಳಿಸಿದೆ. ದಾರಿಯುದ್ದಕ್ಕೂ, ನಾನು ಇತರ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಿದೆ, ಆದರೆ ಪ್ರತಿ ಕೆಲವು ದಿನಗಳಿಗೊಮ್ಮೆ ನಾನು ಕೆಲವು ಗಂಟೆಗಳ ಕಾಲ ಈ ಕೋಡ್‌ಗೆ ಮರಳಿದೆ. ಇದು ಸಂಕಟವಾಗಿತ್ತು.

ರೋಗಲಕ್ಷಣವು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ: ನೀವು ಆಟದ ಪ್ರಸ್ತುತ ಪ್ಲೇಥ್ರೂ ಅನ್ನು ಉಳಿಸಿದಾಗ ಮತ್ತು ಮೆಮೊರಿ ಕಾರ್ಡ್ ಅನ್ನು ಪ್ರವೇಶಿಸಿದಾಗ, ಎಲ್ಲವೂ ಬಹುತೇಕ ಯಾವಾಗಲೂ ಉತ್ತಮವಾಗಿರುತ್ತದೆ... ಆದರೆ ಕೆಲವೊಮ್ಮೆ ಯಾವುದೇ ಸ್ಪಷ್ಟ ಕಾರಣವಿಲ್ಲದೆ ಓದುವ ಅಥವಾ ಬರೆಯುವ ಕಾರ್ಯಾಚರಣೆಯ ಸಮಯ ಮೀರುತ್ತದೆ. ಸಣ್ಣ ರೆಕಾರ್ಡಿಂಗ್ ಸಾಮಾನ್ಯವಾಗಿ ಮೆಮೊರಿ ಕಾರ್ಡ್ ಅನ್ನು ಹಾನಿಗೊಳಿಸುತ್ತದೆ. ಆಟಗಾರನು ಉಳಿಸಲು ಪ್ರಯತ್ನಿಸಿದಾಗ, ಅವನು ಉಳಿಸಲು ವಿಫಲವಾಗುವುದಿಲ್ಲ, ಆದರೆ ನಕ್ಷೆಯನ್ನು ನಾಶಪಡಿಸುತ್ತಾನೆ. ಅಮೇಧ್ಯ.

ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ, ಸೋನಿಯಲ್ಲಿ ನಮ್ಮ ನಿರ್ಮಾಪಕ, ಕೋನಿ ಬಸ್, ಪ್ಯಾನಿಕ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿತು. ಈ ದೋಷದೊಂದಿಗೆ ನಾವು ಆಟವನ್ನು ಸಾಗಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ ಮತ್ತು ಆರು ವಾರಗಳ ನಂತರ ಸಮಸ್ಯೆಗೆ ಕಾರಣವೇನು ಎಂದು ನನಗೆ ಅರ್ಥವಾಗಲಿಲ್ಲ. ಕೋನಿ ಮೂಲಕ, ನಾವು ಇತರ PS1 ಡೆವಲಪರ್‌ಗಳನ್ನು ಸಂಪರ್ಕಿಸಿದ್ದೇವೆ: ಯಾರಾದರೂ ಇದೇ ರೀತಿಯದ್ದನ್ನು ಎದುರಿಸಿದ್ದೀರಾ? ಸಂ. ಮೆಮೊರಿ ಕಾರ್ಡ್‌ನಲ್ಲಿ ಯಾರಿಗೂ ಸಮಸ್ಯೆಗಳಿಲ್ಲ.

ಡೀಬಗ್ ಮಾಡಲು ನಿಮಗೆ ಯಾವುದೇ ಆಲೋಚನೆಗಳಿಲ್ಲದಿದ್ದಾಗ, "ವಿಭಜನೆ ಮತ್ತು ವಶಪಡಿಸಿಕೊಳ್ಳುವುದು" ಮಾತ್ರ ಉಳಿದಿದೆ: ದೋಷಪೂರಿತ ಪ್ರೋಗ್ರಾಂನಿಂದ ಹೆಚ್ಚು ಹೆಚ್ಚು ಕೋಡ್ ಅನ್ನು ತೆಗೆದುಹಾಕಿ, ಅದು ಇನ್ನೂ ಸಮಸ್ಯೆಯನ್ನು ಉಂಟುಮಾಡುವ ತುಲನಾತ್ಮಕವಾಗಿ ಸಣ್ಣ ತುಣುಕು ಉಳಿದಿದೆ. ಅಂದರೆ, ದೋಷವನ್ನು ಒಳಗೊಂಡಿರುವ ಭಾಗವು ಉಳಿಯುವವರೆಗೆ ನೀವು ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ತುಂಡು ತುಂಡಾಗಿ ಕತ್ತರಿಸಿ.

ಆದರೆ ವಿಷಯವೆಂದರೆ, ವೀಡಿಯೊ ಗೇಮ್‌ನಿಂದ ತುಂಡುಗಳನ್ನು ಕತ್ತರಿಸುವುದು ತುಂಬಾ ಕಷ್ಟ. ಗುರುತ್ವಾಕರ್ಷಣೆಯನ್ನು ಅನುಕರಿಸುವ ಕೋಡ್ ಅನ್ನು ನೀವು ತೆಗೆದುಹಾಕಿದರೆ ಅದನ್ನು ಹೇಗೆ ಚಲಾಯಿಸುವುದು? ಅಥವಾ ಅಕ್ಷರಗಳನ್ನು ಚಿತ್ರಿಸುವುದೇ?

ಆದ್ದರಿಂದ, ನಾವು ಸಂಪೂರ್ಣ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಸ್ಟಬ್‌ಗಳೊಂದಿಗೆ ಬದಲಾಯಿಸಬೇಕಾಗಿದೆ, ಅದು ಉಪಯುಕ್ತವಾದದ್ದನ್ನು ಮಾಡುವಂತೆ ನಟಿಸುತ್ತದೆ, ಆದರೆ ವಾಸ್ತವವಾಗಿ ದೋಷಗಳನ್ನು ಹೊಂದಿರದ ಸರಳವಾದದ್ದನ್ನು ಮಾಡಿ. ಕನಿಷ್ಠ ಕೆಲಸ ಮಾಡಲು ನಾವು ಆಟಕ್ಕೆ ಅಂತಹ ಊರುಗೋಲುಗಳನ್ನು ಬರೆಯಬೇಕು. ಇದು ನಿಧಾನ ಮತ್ತು ನೋವಿನ ಪ್ರಕ್ರಿಯೆ.

ಸಂಕ್ಷಿಪ್ತವಾಗಿ, ನಾನು ಅದನ್ನು ಮಾಡಿದ್ದೇನೆ. ಆಟವನ್ನು ಚಲಾಯಿಸಲು ಸಿಸ್ಟಮ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುವ, ರೆಂಡರಿಂಗ್ ಹಾರ್ಡ್‌ವೇರ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುವ ಆರಂಭಿಕ ಕೋಡ್‌ನೊಂದಿಗೆ ನಾನು ಉಳಿಯುವವರೆಗೆ ನಾನು ಹೆಚ್ಚು ಹೆಚ್ಚು ಕೋಡ್ ತುಣುಕುಗಳನ್ನು ತೆಗೆದುಹಾಕಿದ್ದೇನೆ. ಸಹಜವಾಗಿ, ಈ ಹಂತದಲ್ಲಿ ನಾನು ಉಳಿಸಲು ಮತ್ತು ಲೋಡ್ ಮೆನುವನ್ನು ರಚಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ, ಏಕೆಂದರೆ ನಾನು ಎಲ್ಲಾ ಗ್ರಾಫಿಕ್ಸ್ ಕೋಡ್‌ಗಾಗಿ ಸ್ಟಬ್ ಅನ್ನು ರಚಿಸಬೇಕಾಗಿದೆ. ಆದರೆ ನಾನು (ಅದೃಶ್ಯ) ಸೇವ್ ಮತ್ತು ಲೋಡ್ ಸ್ಕ್ರೀನ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಬಳಕೆದಾರರಂತೆ ನಟಿಸಬಹುದು ಮತ್ತು ಉಳಿಸಲು ಮತ್ತು ನಂತರ ಮೆಮೊರಿ ಕಾರ್ಡ್‌ಗೆ ಬರೆಯಲು ಕೇಳಬಹುದು.

ಇದು ನನಗೆ ಇನ್ನೂ ಮೇಲಿನ ಸಮಸ್ಯೆಯನ್ನು ಹೊಂದಿರುವ ಒಂದು ಸಣ್ಣ ಕೋಡ್‌ನೊಂದಿಗೆ ಉಳಿದಿದೆ - ಆದರೆ ಅದು ಇನ್ನೂ ಯಾದೃಚ್ಛಿಕವಾಗಿ ನಡೆಯುತ್ತಿದೆ! ಹೆಚ್ಚಾಗಿ ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತವೆ, ಆದರೆ ಸಾಂದರ್ಭಿಕವಾಗಿ ದೋಷಗಳು ಇದ್ದವು. ನಾನು ಬಹುತೇಕ ಎಲ್ಲಾ ಆಟದ ಕೋಡ್ ಅನ್ನು ತೆಗೆದುಹಾಕಿದ್ದೇನೆ, ಆದರೆ ದೋಷವು ಇನ್ನೂ ಜೀವಂತವಾಗಿದೆ. ಇದು ಗೊಂದಲಮಯವಾಗಿತ್ತು: ಉಳಿದ ಕೋಡ್ ನಿಜವಾಗಿ ಏನನ್ನೂ ಮಾಡಲಿಲ್ಲ.

ಕೆಲವು ಸಮಯದಲ್ಲಿ, ಬಹುಶಃ ಬೆಳಿಗ್ಗೆ ಮೂರು ಗಂಟೆಯ ಸುಮಾರಿಗೆ, ನನಗೆ ಒಂದು ಆಲೋಚನೆ ಸಂಭವಿಸಿದೆ. ಓದಲು ಮತ್ತು ಬರೆಯಲು (ಇನ್‌ಪುಟ್/ಔಟ್‌ಪುಟ್) ಕಾರ್ಯಾಚರಣೆಗಳು ನಿಖರವಾದ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಮಯವನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ. ನೀವು ಹಾರ್ಡ್ ಡ್ರೈವ್, ಮೆಮೊರಿ ಕಾರ್ಡ್ ಅಥವಾ ಬ್ಲೂಟೂತ್ ಮಾಡ್ಯೂಲ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ, ಓದುವ ಮತ್ತು ಬರೆಯುವ ಜವಾಬ್ದಾರಿಯನ್ನು ಹೊಂದಿರುವ ಕಡಿಮೆ-ಹಂತದ ಕೋಡ್ ಗಡಿಯಾರದ ದ್ವಿದಳ ಧಾನ್ಯಗಳಿಗೆ ಅನುಗುಣವಾಗಿ ಮಾಡುತ್ತದೆ.

ಗಡಿಯಾರದ ಸಹಾಯದಿಂದ, ಪ್ರೊಸೆಸರ್‌ಗೆ ನೇರವಾಗಿ ಸಂಪರ್ಕ ಹೊಂದಿಲ್ಲದ ಸಾಧನವನ್ನು ಪ್ರೊಸೆಸರ್‌ನಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಕೋಡ್‌ನೊಂದಿಗೆ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲಾಗುತ್ತದೆ. ಗಡಿಯಾರವು ಬಾಡ್ ದರವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ - ಡೇಟಾವನ್ನು ವರ್ಗಾಯಿಸುವ ವೇಗ. ಸಮಯದೊಂದಿಗೆ ಗೊಂದಲವಿದ್ದರೆ, ಹಾರ್ಡ್‌ವೇರ್ ಅಥವಾ ಸಾಫ್ಟ್‌ವೇರ್ ಅಥವಾ ಎರಡನ್ನೂ ಸಹ ಗೊಂದಲಗೊಳಿಸಲಾಗುತ್ತದೆ. ಮತ್ತು ಇದು ತುಂಬಾ ಕೆಟ್ಟದು, ಏಕೆಂದರೆ ಡೇಟಾ ಹಾನಿಗೊಳಗಾಗಬಹುದು.

ನಮ್ಮ ಕೋಡ್‌ನಲ್ಲಿ ಏನಾದರೂ ಸಮಯವನ್ನು ಗೊಂದಲಗೊಳಿಸಿದರೆ ಏನು? ನಾನು ಪರೀಕ್ಷಾ ಪ್ರೋಗ್ರಾಂ ಕೋಡ್‌ನಲ್ಲಿ ಇದಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಎಲ್ಲವನ್ನೂ ಪರಿಶೀಲಿಸಿದ್ದೇನೆ ಮತ್ತು ನಾವು ಪ್ರೊಗ್ರಾಮೆಬಲ್ ಟೈಮರ್ ಅನ್ನು PS1 ಗೆ 1 kHz (ಸೆಕೆಂಡಿಗೆ 1000 ಉಣ್ಣಿ) ಹೊಂದಿಸಿದ್ದೇವೆ ಎಂದು ಗಮನಿಸಿದ್ದೇವೆ. ಇದು ಸಾಕಷ್ಟು ಆಗಿದೆ; ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಕನ್ಸೋಲ್ ಪ್ರಾರಂಭವಾದಾಗ, ಅದು 100 Hz ನಲ್ಲಿ ಚಲಿಸುತ್ತದೆ. ಮತ್ತು ಹೆಚ್ಚಿನ ಆಟಗಳು ಈ ಆವರ್ತನವನ್ನು ಬಳಸುತ್ತವೆ.

ಆಂಡಿ, ಆಟದ ಡೆವಲಪರ್, ಟೈಮರ್ ಅನ್ನು 1 kHz ಗೆ ಹೊಂದಿಸಿ ಇದರಿಂದ ಚಲನೆಗಳನ್ನು ಹೆಚ್ಚು ನಿಖರವಾಗಿ ಲೆಕ್ಕಹಾಕಲಾಗುತ್ತದೆ. ಆಂಡಿ ಅತಿರೇಕಕ್ಕೆ ಹೋಗುತ್ತಾನೆ, ಮತ್ತು ನಾವು ಗುರುತ್ವಾಕರ್ಷಣೆಯನ್ನು ಅನುಕರಿಸಿದರೆ, ನಾವು ಅದನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ನಿಖರವಾಗಿ ಮಾಡುತ್ತೇವೆ!

ಆದರೆ ಟೈಮರ್ ಅನ್ನು ವೇಗಗೊಳಿಸುವುದು ಪ್ರೋಗ್ರಾಂನ ಒಟ್ಟಾರೆ ಸಮಯವನ್ನು ಹೇಗಾದರೂ ಪರಿಣಾಮ ಬೀರಿದರೆ ಮತ್ತು ಆದ್ದರಿಂದ ಮೆಮೊರಿ ಕಾರ್ಡ್ಗಾಗಿ ಬಾಡ್ ದರವನ್ನು ನಿಯಂತ್ರಿಸುವ ಗಡಿಯಾರ ಏನು?

ನಾನು ಟೈಮರ್ ಕೋಡ್ ಅನ್ನು ಕಾಮೆಂಟ್ ಮಾಡಿದ್ದೇನೆ. ದೋಷ ಮತ್ತೆ ಸಂಭವಿಸಲಿಲ್ಲ. ಆದರೆ ನಾವು ಅದನ್ನು ಸರಿಪಡಿಸಿದ್ದೇವೆ ಎಂದು ಇದರ ಅರ್ಥವಲ್ಲ, ಏಕೆಂದರೆ ವೈಫಲ್ಯವು ಯಾದೃಚ್ಛಿಕವಾಗಿ ಸಂಭವಿಸಿದೆ. ನಾನು ಅದೃಷ್ಟವಂತನಾಗಿದ್ದರೆ ಏನು?

ಕೆಲವು ದಿನಗಳ ನಂತರ ನಾನು ಪರೀಕ್ಷಾ ಕಾರ್ಯಕ್ರಮದೊಂದಿಗೆ ಮತ್ತೊಮ್ಮೆ ಪ್ರಯೋಗಿಸಿದೆ. ದೋಷ ಮರುಕಳಿಸಲಿಲ್ಲ. ನಾನು ಸಂಪೂರ್ಣ ಆಟದ ಕೋಡ್‌ಬೇಸ್‌ಗೆ ಹಿಂತಿರುಗಿದೆ ಮತ್ತು ಸೇವ್ ಮತ್ತು ಲೋಡ್ ಕೋಡ್ ಅನ್ನು ಮಾರ್ಪಡಿಸಿದೆ ಆದ್ದರಿಂದ ಪ್ರೊಗ್ರಾಮೆಬಲ್ ಟೈಮರ್ ಮೆಮೊರಿ ಕಾರ್ಡ್ ಅನ್ನು ಪ್ರವೇಶಿಸುವ ಮೊದಲು ಅದರ ಮೂಲ ಮೌಲ್ಯಕ್ಕೆ (100Hz) ಮರುಹೊಂದಿಸುತ್ತದೆ ಮತ್ತು ನಂತರ 1kHz ಗೆ ಮರುಹೊಂದಿಸುತ್ತದೆ. ಹೆಚ್ಚಿನ ಕುಸಿತಗಳು ಇರಲಿಲ್ಲ.

ಆದರೆ ಇದು ಏಕೆ ಸಂಭವಿಸಿತು?

ನಾನು ಮತ್ತೆ ಪರೀಕ್ಷಾ ಕಾರ್ಯಕ್ರಮಕ್ಕೆ ಮರಳಿದೆ. 1 kHz ಟೈಮರ್‌ನೊಂದಿಗೆ ದೋಷ ಸಂಭವಿಸುವಲ್ಲಿ ಕೆಲವು ಮಾದರಿಯನ್ನು ಕಂಡುಹಿಡಿಯಲು ನಾನು ಪ್ರಯತ್ನಿಸಿದೆ. ಯಾರಾದರೂ PS1 ನಿಯಂತ್ರಕದೊಂದಿಗೆ ಆಡಿದಾಗ ದೋಷ ಸಂಭವಿಸುತ್ತದೆ ಎಂದು ಅಂತಿಮವಾಗಿ ನಾನು ಗಮನಿಸಿದ್ದೇನೆ. ನಾನು ಇದನ್ನು ಅಪರೂಪವಾಗಿ ಮಾಡುತ್ತೇನೆ - ಸೇವ್ ಮತ್ತು ಲೋಡ್ ಕೋಡ್ ಅನ್ನು ಪರೀಕ್ಷಿಸುವಾಗ ನನಗೆ ನಿಯಂತ್ರಕ ಏಕೆ ಬೇಕು? - ನಾನು ಈ ಅವಲಂಬನೆಯನ್ನು ಗಮನಿಸಲಿಲ್ಲ. ಆದರೆ ಒಂದು ದಿನ ನಮ್ಮ ಕಲಾವಿದರೊಬ್ಬರು ನಾನು ಪರೀಕ್ಷೆಯನ್ನು ಮುಗಿಸಲು ಕಾಯುತ್ತಿದ್ದರು - ನಾನು ಬಹುಶಃ ಆ ಕ್ಷಣದಲ್ಲಿ ಶಪಿಸುತ್ತಿದ್ದೆ - ಮತ್ತು ಭಯದಿಂದ ತನ್ನ ಕೈಯಲ್ಲಿ ನಿಯಂತ್ರಕವನ್ನು ತಿರುಗಿಸಿದನು. ದೋಷ ಕಂಡುಬಂದಿದೆ. "ನಿರೀಕ್ಷಿಸಿ, ಏನು?!" ಸರಿ, ಮತ್ತೆ ಮಾಡಿ! ”

ಈ ಎರಡು ಘಟನೆಗಳು ಪರಸ್ಪರ ಸಂಬಂಧ ಹೊಂದಿವೆ ಎಂದು ನಾನು ಅರಿತುಕೊಂಡಾಗ, ನಾನು ದೋಷವನ್ನು ಸುಲಭವಾಗಿ ಪುನರುತ್ಪಾದಿಸಲು ಸಾಧ್ಯವಾಯಿತು: ನಾನು ಮೆಮೊರಿ ಕಾರ್ಡ್‌ಗೆ ರೆಕಾರ್ಡಿಂಗ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದೆ, ನಿಯಂತ್ರಕವನ್ನು ಸರಿಸಿದ್ದೇನೆ ಮತ್ತು ಮೆಮೊರಿ ಕಾರ್ಡ್ ಅನ್ನು ಹಾಳುಮಾಡಿದೆ. ನನಗೆ ಇದು ಹಾರ್ಡ್‌ವೇರ್ ಬಗ್‌ನಂತೆ ಕಂಡಿತು.

ನಾನು ಕೋನಿಗೆ ಬಂದು ನನ್ನ ಆವಿಷ್ಕಾರದ ಬಗ್ಗೆ ಹೇಳಿದೆ. ಅವರು PS1 ಅನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಿದ ಎಂಜಿನಿಯರ್‌ಗಳಲ್ಲಿ ಒಬ್ಬರಿಗೆ ಮಾಹಿತಿಯನ್ನು ರವಾನಿಸಿದರು. "ಅಸಾಧ್ಯ," ಅವರು ಉತ್ತರಿಸಿದರು, "ಇದು ಹಾರ್ಡ್‌ವೇರ್ ಸಮಸ್ಯೆಯಾಗಿರಬಾರದು." ನಮಗಾಗಿ ಸಂಭಾಷಣೆಯನ್ನು ಏರ್ಪಡಿಸಲು ನಾನು ಕೋನಿಯನ್ನು ಕೇಳಿದೆ.

ಎಂಜಿನಿಯರ್ ನನ್ನನ್ನು ಕರೆದರು ಮತ್ತು ನಾವು ಅವರ ಮುರಿದ ಇಂಗ್ಲಿಷ್ ಮತ್ತು ನನ್ನ (ಅತ್ಯಂತ) ಮುರಿದ ಜಪಾನೀಸ್‌ನಲ್ಲಿ ವಾದಿಸಿದೆವು. ಅಂತಿಮವಾಗಿ ನಾನು ಹೇಳಿದೆ, "ನನ್ನ 30 ಸಾಲಿನ ಪರೀಕ್ಷಾ ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಕಳುಹಿಸಲು ನನಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಡಿ, ಅಲ್ಲಿ ನಿಯಂತ್ರಕವನ್ನು ಚಲಿಸುವಿಕೆಯು ದೋಷವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ." ಅವರು ಒಪ್ಪಿದರು. ಇದು ಸಮಯ ವ್ಯರ್ಥ ಮತ್ತು ಅವರು ಹೊಸ ಯೋಜನೆಯಲ್ಲಿ ಕೆಲಸದಲ್ಲಿ ನಿರತರಾಗಿದ್ದಾರೆ ಎಂದು ಹೇಳಿದರು, ಆದರೆ ನಾವು ಸೋನಿಗಾಗಿ ಬಹಳ ಮುಖ್ಯವಾದ ಡೆವಲಪರ್ ಆಗಿರುವುದರಿಂದ ಬಿಟ್ಟುಕೊಡುತ್ತೇವೆ ಎಂದು ಹೇಳಿದರು. ನಾನು ನನ್ನ ಪರೀಕ್ಷಾ ಕಾರ್ಯಕ್ರಮವನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸಿ ಅವನಿಗೆ ಕಳುಹಿಸಿದೆ.

ಮರುದಿನ ಸಂಜೆ (ನಾವು ಲಾಸ್ ಏಂಜಲೀಸ್‌ನಲ್ಲಿದ್ದೇವೆ ಮತ್ತು ಅವರು ಟೋಕಿಯೊದಲ್ಲಿದ್ದರು) ಅವರು ನನ್ನನ್ನು ಕರೆದು ಕ್ಷಮೆಯಾಚಿಸಿದರು. ಇದು ಹಾರ್ಡ್‌ವೇರ್ ಸಮಸ್ಯೆಯಾಗಿತ್ತು.

ದೋಷವು ನಿಖರವಾಗಿ ಏನೆಂದು ನನಗೆ ತಿಳಿದಿಲ್ಲ, ಆದರೆ ಸೋನಿ ಪ್ರಧಾನ ಕಛೇರಿಯಲ್ಲಿ ನಾನು ಕೇಳಿದ ವಿಷಯದಿಂದ, ನೀವು ಟೈಮರ್ ಅನ್ನು ಸಾಕಷ್ಟು ಹೆಚ್ಚಿನ ಮೌಲ್ಯಕ್ಕೆ ಹೊಂದಿಸಿದರೆ, ಅದು ಟೈಮರ್ ಸ್ಫಟಿಕದ ಸಮೀಪದಲ್ಲಿರುವ ಮದರ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿನ ಘಟಕಗಳೊಂದಿಗೆ ಮಧ್ಯಪ್ರವೇಶಿಸುತ್ತದೆ. ಅವುಗಳಲ್ಲಿ ಒಂದು ಮೆಮೊರಿ ಕಾರ್ಡ್‌ಗಾಗಿ ಬಾಡ್ ದರ ನಿಯಂತ್ರಕವಾಗಿತ್ತು, ಇದು ನಿಯಂತ್ರಕಗಳಿಗೆ ಬಾಡ್ ದರವನ್ನು ಸಹ ಹೊಂದಿಸುತ್ತದೆ. ನಾನು ಇಂಜಿನಿಯರ್ ಅಲ್ಲ, ಹಾಗಾಗಿ ನಾನು ಏನಾದರೂ ಗೊಂದಲಕ್ಕೊಳಗಾಗಿರಬಹುದು.

ಆದರೆ ಬಾಟಮ್ ಲೈನ್ ಎಂದರೆ ಮದರ್ಬೋರ್ಡ್ನಲ್ಲಿನ ಘಟಕಗಳ ನಡುವೆ ಹಸ್ತಕ್ಷೇಪವಿದೆ. ಮತ್ತು 1 kHz ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಟೈಮರ್ನೊಂದಿಗೆ ನಿಯಂತ್ರಕ ಪೋರ್ಟ್ ಮತ್ತು ಮೆಮೊರಿ ಕಾರ್ಡ್ ಪೋರ್ಟ್ ಮೂಲಕ ಡೇಟಾವನ್ನು ಏಕಕಾಲದಲ್ಲಿ ರವಾನಿಸುವಾಗ, ಬಿಟ್ಗಳು ಕಳೆದುಹೋಗಿವೆ, ಡೇಟಾ ಕಳೆದುಹೋಗಿದೆ ಮತ್ತು ಕಾರ್ಡ್ ಹಾನಿಯಾಗಿದೆ.

ಕೆಟ್ಟ ಹಸುಗಳು

1980 ರ ದಶಕದಲ್ಲಿ, ನನ್ನ ಮಾರ್ಗದರ್ಶಕ ಸೆರ್ಗೆಯ್ SM-1800 ಗಾಗಿ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಬರೆದರು, ಇದು PDP-11 ನ ಸೋವಿಯತ್ ಕ್ಲೋನ್. ಈ ಮೈಕ್ರೊಕಂಪ್ಯೂಟರ್ ಅನ್ನು ಯುಎಸ್ಎಸ್ಆರ್ನ ಪ್ರಮುಖ ಸಾರಿಗೆ ಕೇಂದ್ರವಾದ ಸ್ವರ್ಡ್ಲೋವ್ಸ್ಕ್ ಬಳಿಯ ರೈಲ್ವೆ ನಿಲ್ದಾಣದಲ್ಲಿ ಸ್ಥಾಪಿಸಲಾಗಿದೆ. ಹೊಸ ವ್ಯವಸ್ಥೆಯನ್ನು ವ್ಯಾಗನ್‌ಗಳು ಮತ್ತು ಸರಕು ಸಾಗಣೆಯ ಮಾರ್ಗಕ್ಕಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಆದರೆ ಇದು ಯಾದೃಚ್ಛಿಕ ಕ್ರ್ಯಾಶ್‌ಗಳು ಮತ್ತು ಕ್ರ್ಯಾಶ್‌ಗಳಿಗೆ ಕಾರಣವಾದ ಕಿರಿಕಿರಿ ದೋಷವನ್ನು ಒಳಗೊಂಡಿತ್ತು. ಯಾರಾದರೂ ಸಂಜೆ ಮನೆಗೆ ಹೋದಾಗ ಯಾವಾಗಲೂ ಬೀಳುವಿಕೆ ಸಂಭವಿಸಿದೆ. ಆದರೆ ಮರುದಿನ ಸಂಪೂರ್ಣ ತನಿಖೆಯ ಹೊರತಾಗಿಯೂ, ಎಲ್ಲಾ ಕೈಪಿಡಿ ಮತ್ತು ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆಗಳಲ್ಲಿ ಕಂಪ್ಯೂಟರ್ ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿತು. ಇದು ಸಾಮಾನ್ಯವಾಗಿ ರೇಸ್ ಸ್ಥಿತಿಯನ್ನು ಸೂಚಿಸುತ್ತದೆ ಅಥವಾ ಕೆಲವು ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಸಂಭವಿಸುವ ಇತರ ಸ್ಪರ್ಧಾತ್ಮಕ ದೋಷವನ್ನು ಸೂಚಿಸುತ್ತದೆ. ತಡರಾತ್ರಿಯಲ್ಲಿ ಕರೆಗಳಿಂದ ಬೇಸತ್ತ ಸೆರ್ಗೆಯ್ ಅದರ ಕೆಳಭಾಗಕ್ಕೆ ಹೋಗಲು ನಿರ್ಧರಿಸಿದರು, ಮತ್ತು ಮೊದಲನೆಯದಾಗಿ, ಮಾರ್ಷಲಿಂಗ್ ಅಂಗಳದಲ್ಲಿ ಯಾವ ಪರಿಸ್ಥಿತಿಗಳು ಕಂಪ್ಯೂಟರ್ ಸ್ಥಗಿತಕ್ಕೆ ಕಾರಣವಾಯಿತು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ.

ಮೊದಲಿಗೆ, ಅವರು ಎಲ್ಲಾ ವಿವರಿಸಲಾಗದ ಜಲಪಾತಗಳ ಅಂಕಿಅಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸಿದರು ಮತ್ತು ದಿನಾಂಕ ಮತ್ತು ಸಮಯದ ಪ್ರಕಾರ ಗ್ರಾಫ್ ಅನ್ನು ರಚಿಸಿದರು. ಮಾದರಿಯು ಸ್ಪಷ್ಟವಾಗಿತ್ತು. ಇನ್ನೂ ಕೆಲವು ದಿನಗಳವರೆಗೆ ಗಮನಿಸಿದ ನಂತರ, ಭವಿಷ್ಯದ ಸಿಸ್ಟಮ್ ವೈಫಲ್ಯಗಳ ಸಮಯವನ್ನು ಅವರು ಸುಲಭವಾಗಿ ಊಹಿಸಬಹುದು ಎಂದು ಸೆರ್ಗೆಯ್ ಅರಿತುಕೊಂಡರು.

ನಿಲ್ದಾಣವು ಉತ್ತರ ಉಕ್ರೇನ್ ಮತ್ತು ಪಶ್ಚಿಮ ರಶಿಯಾದಿಂದ ರೈಲು ಲೋಡ್‌ಗಳನ್ನು ವಿಂಗಡಿಸುವಾಗ ಮಾತ್ರ ಅಡೆತಡೆಗಳು ಸಂಭವಿಸಿದವು ಎಂದು ಅವರು ಶೀಘ್ರದಲ್ಲೇ ತಿಳಿದುಕೊಂಡರು. ಇದು ಸ್ವತಃ ವಿಚಿತ್ರವಾಗಿತ್ತು, ಏಕೆಂದರೆ ಕಸಾಯಿಖಾನೆಯು ಕಝಾಕಿಸ್ತಾನ್‌ನಲ್ಲಿ ಹೆಚ್ಚು ಹತ್ತಿರವಿರುವ ಸಾಕಣೆ ಕೇಂದ್ರಗಳಿಂದ ಸರಬರಾಜು ಮಾಡಲ್ಪಟ್ಟಿದೆ.

ಚೆರ್ನೋಬಿಲ್ ಪರಮಾಣು ವಿದ್ಯುತ್ ಸ್ಥಾವರವು 1986 ರಲ್ಲಿ ಸ್ಫೋಟಗೊಂಡಿತು ಮತ್ತು ವಿಕಿರಣಶೀಲ ವಿಕಿರಣವು ಸುತ್ತಮುತ್ತಲಿನ ಪ್ರದೇಶಗಳನ್ನು ವಾಸಯೋಗ್ಯವಲ್ಲದಂತಾಯಿತು. ಉತ್ತರ ಉಕ್ರೇನ್, ಬೆಲಾರಸ್ ಮತ್ತು ಪಶ್ಚಿಮ ರಷ್ಯಾದಲ್ಲಿ ವಿಶಾಲ ಪ್ರದೇಶಗಳು ಕಲುಷಿತಗೊಂಡಿವೆ. ಬರುವ ಗಾಡಿಗಳಲ್ಲಿ ಹೆಚ್ಚಿನ ಮಟ್ಟದ ವಿಕಿರಣವನ್ನು ಅನುಮಾನಿಸಿದ ಸೆರ್ಗೆಯ್ ಈ ಸಿದ್ಧಾಂತವನ್ನು ಪರೀಕ್ಷಿಸಲು ಒಂದು ವಿಧಾನವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದರು. ಜನಸಂಖ್ಯೆಯು ಡೋಸಿಮೀಟರ್ಗಳನ್ನು ಹೊಂದುವುದನ್ನು ನಿಷೇಧಿಸಲಾಗಿದೆ, ಆದ್ದರಿಂದ ಸೆರ್ಗೆಯ್ ರೈಲ್ವೇ ನಿಲ್ದಾಣದಲ್ಲಿ ಹಲವಾರು ಮಿಲಿಟರಿ ಪುರುಷರೊಂದಿಗೆ ನೋಂದಾಯಿಸಿಕೊಂಡರು. ಹಲವಾರು ವೋಡ್ಕಾ ಪಾನೀಯಗಳನ್ನು ಸೇವಿಸಿದ ನಂತರ, ಅನುಮಾನಾಸ್ಪದ ಗಾಡಿಗಳಲ್ಲಿ ವಿಕಿರಣ ಮಟ್ಟವನ್ನು ಅಳೆಯಲು ಸೈನಿಕನಿಗೆ ಮನವರಿಕೆ ಮಾಡಲು ಅವನು ಯಶಸ್ವಿಯಾದನು. ಸಾಮಾನ್ಯ ಮೌಲ್ಯಗಳಿಗಿಂತ ಮಟ್ಟವು ಹಲವಾರು ಪಟ್ಟು ಹೆಚ್ಚಾಗಿದೆ ಎಂದು ಅದು ಬದಲಾಯಿತು.

ಜಾನುವಾರುಗಳು ಸಾಕಷ್ಟು ವಿಕಿರಣವನ್ನು ಹೊರಸೂಸುವುದು ಮಾತ್ರವಲ್ಲದೆ, ಅದರ ಮಟ್ಟವು ತುಂಬಾ ಹೆಚ್ಚಿತ್ತು, ಇದು ನಿಲ್ದಾಣದ ಪಕ್ಕದ ಕಟ್ಟಡದಲ್ಲಿ ನೆಲೆಗೊಂಡಿದ್ದ SM-1800 ನ ಸ್ಮರಣೆಯಲ್ಲಿ ಬಿಟ್ಗಳ ಯಾದೃಚ್ಛಿಕ ನಷ್ಟಕ್ಕೆ ಕಾರಣವಾಯಿತು.

ಯುಎಸ್ಎಸ್ಆರ್ನಲ್ಲಿ ಆಹಾರದ ಕೊರತೆ ಇತ್ತು ಮತ್ತು ಚೆರ್ನೋಬಿಲ್ ಮಾಂಸವನ್ನು ದೇಶದ ಇತರ ಪ್ರದೇಶಗಳ ಮಾಂಸದೊಂದಿಗೆ ಬೆರೆಸಲು ಅಧಿಕಾರಿಗಳು ನಿರ್ಧರಿಸಿದರು. ಅಮೂಲ್ಯವಾದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳದೆ ವಿಕಿರಣಶೀಲತೆಯ ಒಟ್ಟಾರೆ ಮಟ್ಟವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಇದು ಸಾಧ್ಯವಾಗಿಸಿತು. ಇದರ ಬಗ್ಗೆ ತಿಳಿದ ನಂತರ, ಸೆರ್ಗೆಯ್ ತಕ್ಷಣವೇ ವಲಸೆಗಾಗಿ ದಾಖಲೆಗಳನ್ನು ಭರ್ತಿ ಮಾಡಿದರು. ಮತ್ತು ವಿಕಿರಣ ಮಟ್ಟವು ಕಾಲಾನಂತರದಲ್ಲಿ ಕಡಿಮೆಯಾದಾಗ ಕಂಪ್ಯೂಟರ್ ಕ್ರ್ಯಾಶ್ಗಳು ತಮ್ಮದೇ ಆದ ಮೇಲೆ ನಿಲ್ಲಿಸಿದವು.

ಕೊಳವೆಗಳ ಮೂಲಕ

ಒಂದಾನೊಂದು ಕಾಲದಲ್ಲಿ, Movietech Solutions ಚಿತ್ರಮಂದಿರಗಳಿಗಾಗಿ ಸಾಫ್ಟ್ವೇರ್ ಅನ್ನು ರಚಿಸಿತು, ಲೆಕ್ಕಪತ್ರ ನಿರ್ವಹಣೆ, ಟಿಕೆಟ್ ಮಾರಾಟ ಮತ್ತು ಸಾಮಾನ್ಯ ನಿರ್ವಹಣೆಗಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಪ್ರಮುಖ ಅಪ್ಲಿಕೇಶನ್‌ನ DOS ಆವೃತ್ತಿಯು ಉತ್ತರ ಅಮೆರಿಕಾದಲ್ಲಿನ ಸಣ್ಣ ಮತ್ತು ಮಧ್ಯಮ ಗಾತ್ರದ ಚಲನಚಿತ್ರ ಥಿಯೇಟರ್ ಸರಪಳಿಗಳಲ್ಲಿ ಸಾಕಷ್ಟು ಜನಪ್ರಿಯವಾಗಿದೆ. ಆದ್ದರಿಂದ ವಿಂಡೋಸ್ 95 ಆವೃತ್ತಿಯನ್ನು ಘೋಷಿಸಿದಾಗ, ಇತ್ತೀಚಿನ ಟಚ್ ಸ್ಕ್ರೀನ್‌ಗಳು ಮತ್ತು ಸ್ವಯಂ-ಸೇವಾ ಕಿಯೋಸ್ಕ್‌ಗಳೊಂದಿಗೆ ಸಂಯೋಜಿಸಲ್ಪಟ್ಟಾಗ ಮತ್ತು ಎಲ್ಲಾ ರೀತಿಯ ವರದಿ ಮಾಡುವ ಸಾಧನಗಳೊಂದಿಗೆ ಸಜ್ಜುಗೊಂಡಾಗ, ಅದು ಶೀಘ್ರವಾಗಿ ಜನಪ್ರಿಯವಾಯಿತು. ಹೆಚ್ಚಾಗಿ ನವೀಕರಣವು ಸಮಸ್ಯೆಗಳಿಲ್ಲದೆ ಹೋಯಿತು. ಸ್ಥಳೀಯ ಐಟಿ ಸಿಬ್ಬಂದಿ ಹೊಸ ಉಪಕರಣಗಳನ್ನು ಸ್ಥಾಪಿಸಿದರು, ಡೇಟಾ ವಲಸೆ, ಮತ್ತು ವ್ಯಾಪಾರ ಮುಂದುವರೆಯಿತು. ಅದು ಉಳಿಯದಿದ್ದಾಗ ಹೊರತುಪಡಿಸಿ. ಇದು ಸಂಭವಿಸಿದಾಗ, ಕಂಪನಿಯು "ದಿ ಕ್ಲೀನರ್" ಎಂಬ ಅಡ್ಡಹೆಸರಿನ ಜೇಮ್ಸ್ ಅನ್ನು ಕಳುಹಿಸುತ್ತದೆ.

ಅಡ್ಡಹೆಸರು ಅಸಹ್ಯಕರ ಪ್ರಕಾರವನ್ನು ಸೂಚಿಸಿದರೂ, ಕ್ಲೀನರ್ ಕೇವಲ ಬೋಧಕ, ಸ್ಥಾಪಕ ಮತ್ತು ಜಾಕ್-ಆಫ್-ಆಲ್-ಟ್ರೇಡ್‌ಗಳ ಸಂಯೋಜನೆಯಾಗಿದೆ. ಜೇಮ್ಸ್ ಕ್ಲೈಂಟ್‌ನ ಸೈಟ್‌ನಲ್ಲಿ ಎಲ್ಲಾ ಘಟಕಗಳನ್ನು ಒಟ್ಟಿಗೆ ಸೇರಿಸಲು ಕೆಲವು ದಿನಗಳನ್ನು ಕಳೆಯುತ್ತಾರೆ ಮತ್ತು ನಂತರ ಸಿಬ್ಬಂದಿಗೆ ಹೊಸ ಸಿಸ್ಟಮ್ ಅನ್ನು ಹೇಗೆ ಬಳಸಬೇಕೆಂದು ಕಲಿಸಲು, ಉದ್ಭವಿಸಿದ ಯಾವುದೇ ಹಾರ್ಡ್‌ವೇರ್ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಮತ್ತು ಮೂಲಭೂತವಾಗಿ ಅದರ ಶೈಶವಾವಸ್ಥೆಯಲ್ಲಿ ಸಾಫ್ಟ್‌ವೇರ್‌ಗೆ ಸಹಾಯ ಮಾಡುತ್ತಾರೆ.

ಆದ್ದರಿಂದ, ಈ ಒತ್ತಡದ ಸಮಯದಲ್ಲಿ, ಜೇಮ್ಸ್ ಬೆಳಿಗ್ಗೆ ಕಚೇರಿಗೆ ಬಂದರು ಮತ್ತು ಅವರು ತಮ್ಮ ಡೆಸ್ಕ್ ಅನ್ನು ತಲುಪುವ ಮೊದಲು, ಮ್ಯಾನೇಜರ್ ಅವರನ್ನು ಸ್ವಾಗತಿಸಿದರು, ಸಾಮಾನ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚು ಕೆಫೀನ್ ತುಂಬಿದರು.

"ನೀವು ಆದಷ್ಟು ಬೇಗ ನೋವಾ ಸ್ಕಾಟಿಯಾದ ಅನ್ನಾಪೊಲಿಸ್‌ಗೆ ಹೋಗಬೇಕೆಂದು ನಾನು ಹೆದರುತ್ತೇನೆ." ಅವರ ಸಂಪೂರ್ಣ ವ್ಯವಸ್ಥೆಯು ಕುಸಿದಿದೆ, ಮತ್ತು ಅವರ ಇಂಜಿನಿಯರ್‌ಗಳೊಂದಿಗೆ ರಾತ್ರಿ ಕೆಲಸ ಮಾಡಿದ ನಂತರ, ಏನಾಯಿತು ಎಂಬುದನ್ನು ನಾವು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಸರ್ವರ್‌ನಲ್ಲಿ ನೆಟ್‌ವರ್ಕ್ ವಿಫಲವಾಗಿದೆ ಎಂದು ತೋರುತ್ತಿದೆ. ಆದರೆ ಸಿಸ್ಟಮ್ ಹಲವಾರು ನಿಮಿಷಗಳ ಕಾಲ ಚಾಲನೆಯಲ್ಲಿರುವ ನಂತರ ಮಾತ್ರ.

- ಅವರು ಹಳೆಯ ವ್ಯವಸ್ಥೆಗೆ ಮರಳಲಿಲ್ಲವೇ? - ಜೇಮ್ಸ್ ಸಂಪೂರ್ಣವಾಗಿ ಗಂಭೀರವಾಗಿ ಉತ್ತರಿಸಿದನು, ಆದರೂ ಮಾನಸಿಕವಾಗಿ ಅವನು ಆಶ್ಚರ್ಯದಿಂದ ತನ್ನ ಕಣ್ಣುಗಳನ್ನು ವಿಸ್ತರಿಸಿದನು.

— ನಿಖರವಾಗಿ: ಅವರ ಐಟಿ ತಜ್ಞರು “ಆದ್ಯತೆಗಳನ್ನು ಬದಲಾಯಿಸಿದ್ದಾರೆ” ಮತ್ತು ಅವರ ಹಳೆಯ ಸರ್ವರ್‌ನೊಂದಿಗೆ ಹೊರಡಲು ನಿರ್ಧರಿಸಿದ್ದಾರೆ. ಜೇಮ್ಸ್, ಅವರು ಆರು ಸೈಟ್‌ಗಳಲ್ಲಿ ಸಿಸ್ಟಮ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿದರು ಮತ್ತು ಪ್ರೀಮಿಯಂ ಬೆಂಬಲಕ್ಕಾಗಿ ಪಾವತಿಸಿದರು ಮತ್ತು ಅವರ ವ್ಯವಹಾರವು ಈಗ 1950 ರ ದಶಕದಂತೆ ನಡೆಸಲ್ಪಡುತ್ತದೆ.

ಜೇಮ್ಸ್ ಸ್ವಲ್ಪ ನೇರವಾದ.

- ಅದು ಇನ್ನೊಂದು ವಿಷಯ. ಸರಿ, ಪ್ರಾರಂಭಿಸೋಣ.

ಅವರು ಅನ್ನಾಪೊಲಿಸ್‌ಗೆ ಆಗಮಿಸಿದಾಗ, ಅವರು ಮಾಡಿದ ಮೊದಲ ಕೆಲಸವೆಂದರೆ ಸಮಸ್ಯೆಯನ್ನು ಹೊಂದಿರುವ ಗ್ರಾಹಕರ ಮೊದಲ ಥಿಯೇಟರ್ ಅನ್ನು ಕಂಡುಹಿಡಿಯುವುದು. ವಿಮಾನ ನಿಲ್ದಾಣದಲ್ಲಿ ತೆಗೆದ ನಕ್ಷೆಯಲ್ಲಿ, ಎಲ್ಲವೂ ಯೋಗ್ಯವಾಗಿ ಕಂಡುಬಂದಿದೆ, ಆದರೆ ಬಯಸಿದ ವಿಳಾಸದ ಸುತ್ತಲಿನ ಪ್ರದೇಶವು ಅನುಮಾನಾಸ್ಪದವಾಗಿ ಕಾಣುತ್ತದೆ. ಘೆಟ್ಟೋ ಅಲ್ಲ, ಆದರೆ ಫಿಲ್ಮ್ ನಾಯರ್ ಅನ್ನು ನೆನಪಿಸುತ್ತದೆ. ಜೇಮ್ಸ್ ಕರ್ಬ್ ಡೌನ್ಟೌನ್ನಲ್ಲಿ ನಿಲ್ಲಿಸಿದಾಗ, ಒಬ್ಬ ವೇಶ್ಯೆ ಅವನ ಬಳಿಗೆ ಬಂದಳು. ಅನ್ನಾಪೊಲಿಸ್‌ನ ಗಾತ್ರವನ್ನು ಗಮನಿಸಿದರೆ, ಇಡೀ ನಗರದಲ್ಲಿ ಇದು ಒಂದೇ ಆಗಿರಬಹುದು. ಆಕೆಯ ನೋಟವು ತಕ್ಷಣವೇ ದೊಡ್ಡ ಪರದೆಯ ಮೇಲೆ ಹಣಕ್ಕಾಗಿ ಲೈಂಗಿಕತೆಯನ್ನು ನೀಡುವ ಪ್ರಸಿದ್ಧ ಪಾತ್ರವನ್ನು ನೆನಪಿಗೆ ತಂದಿತು. ಇಲ್ಲ, ಜೂಲಿಯಾ ರಾಬರ್ಟ್ಸ್ ಬಗ್ಗೆ ಅಲ್ಲ, ಆದರೆ ಜಾನ್ ವಾಯ್ಟ್ ಬಗ್ಗೆ ["ಮಿಡ್ನೈಟ್ ಕೌಬಾಯ್" ಚಿತ್ರದ ಪ್ರಸ್ತಾಪ - ಅಂದಾಜು. ಲೇನ್].

ವೇಶ್ಯೆಯನ್ನು ದಾರಿಯಲ್ಲಿ ಕಳುಹಿಸಿದ ನಂತರ, ಜೇಮ್ಸ್ ಸಿನೆಮಾಕ್ಕೆ ಹೋದನು. ಸುತ್ತಮುತ್ತಲಿನ ಪ್ರದೇಶವು ಉತ್ತಮಗೊಂಡಿದೆ, ಆದರೆ ಅದು ಇನ್ನೂ ಓಡಿಹೋಗುವ ಅನಿಸಿಕೆ ನೀಡಿತು. ಜೇಮ್ಸ್ ತುಂಬಾ ಚಿಂತಿತರಾಗಿದ್ದರು. ಅವನು ಈ ಹಿಂದೆ ದರಿದ್ರ ಸ್ಥಳಗಳಿಗೆ ಹೋಗಿದ್ದನು. ಮತ್ತು ಇದು ಕೆನಡಾ ಆಗಿತ್ತು, ಅಲ್ಲಿ ಮಗ್ಗರ್‌ಗಳು ಸಹ ನಿಮ್ಮ ವ್ಯಾಲೆಟ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡ ನಂತರ "ಧನ್ಯವಾದಗಳು" ಎಂದು ಹೇಳುವಷ್ಟು ಸಭ್ಯರಾಗಿದ್ದಾರೆ.

ಚಿತ್ರಮಂದಿರದ ಪಕ್ಕದ ಪ್ರವೇಶ ದಟ್ಟವಾದ ಓಣಿಯಲ್ಲಿತ್ತು. ಜೇಮ್ಸ್ ಬಾಗಿಲಿಗೆ ನಡೆದು ಬಡಿದ. ಶೀಘ್ರದಲ್ಲೇ ಅದು ಕ್ರೀಕ್ ಮತ್ತು ಸ್ವಲ್ಪ ತೆರೆಯಿತು.

-ನೀವು ಕ್ಲೀನರ್ ಆಗಿದ್ದೀರಾ? - ಒಳಗಿನಿಂದ ಒರಟಾದ ಧ್ವನಿ ಬಂತು.

- ಹೌದು, ಇದು ನಾನೇ ... ನಾನು ಎಲ್ಲವನ್ನೂ ಸರಿಪಡಿಸಲು ಬಂದಿದ್ದೇನೆ.

ಜೇಮ್ಸ್ ಸಿನಿಮಾ ಲಾಬಿಗೆ ಕಾಲಿಟ್ಟರು. ಮೇಲ್ನೋಟಕ್ಕೆ ಬೇರೆ ದಾರಿಯಿಲ್ಲದ ಕಾರಣ ಸಿಬ್ಬಂದಿ ಪೇಪರ್ ಟಿಕೆಟ್‌ಗಳನ್ನು ಸಂದರ್ಶಕರಿಗೆ ನೀಡಲು ಪ್ರಾರಂಭಿಸಿದರು. ಇದು ಹಣಕಾಸಿನ ವರದಿಯನ್ನು ಕಷ್ಟಕರವಾಗಿಸಿದೆ, ಹೆಚ್ಚು ಆಸಕ್ತಿದಾಯಕ ವಿವರಗಳನ್ನು ಬಿಡಿ. ಆದರೆ ಸಿಬ್ಬಂದಿ ಜೇಮ್ಸ್ ಅವರನ್ನು ಸಮಾಧಾನದಿಂದ ಸ್ವಾಗತಿಸಿ ತಕ್ಷಣವೇ ಸರ್ವರ್ ಕೊಠಡಿಗೆ ಕರೆದೊಯ್ದರು.

ಮೊದಲ ನೋಟದಲ್ಲಿ, ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿತ್ತು. ಜೇಮ್ಸ್ ಸರ್ವರ್‌ಗೆ ಲಾಗ್ ಇನ್ ಮಾಡಿ ಸಾಮಾನ್ಯ ಅನುಮಾನಾಸ್ಪದ ಸ್ಥಳಗಳನ್ನು ಪರಿಶೀಲಿಸಿದರು. ಯಾವ ತೊಂದರೆಯಿಲ್ಲ. ಆದಾಗ್ಯೂ, ಹೆಚ್ಚಿನ ಎಚ್ಚರಿಕೆಯಿಂದ, ಜೇಮ್ಸ್ ಸರ್ವರ್ ಅನ್ನು ಮುಚ್ಚಿದರು, ನೆಟ್ವರ್ಕ್ ಕಾರ್ಡ್ ಅನ್ನು ಬದಲಾಯಿಸಿದರು ಮತ್ತು ಸಿಸ್ಟಮ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸಿದರು. ಅವಳು ತಕ್ಷಣ ಪೂರ್ಣವಾಗಿ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದಳು. ಸಿಬ್ಬಂದಿ ಮತ್ತೆ ಟಿಕೆಟ್ ಮಾರಾಟ ಆರಂಭಿಸಿದರು.

ಜೇಮ್ಸ್ ಮಾರ್ಕ್ ಅವರನ್ನು ಕರೆದು ಪರಿಸ್ಥಿತಿಯನ್ನು ತಿಳಿಸಿದರು. ಜೇಮ್ಸ್ ಸುತ್ತಲೂ ಅಂಟಿಕೊಂಡು ಏನಾದರೂ ಅನಿರೀಕ್ಷಿತ ಸಂಭವಿಸಿದರೆ ನೋಡಲು ಬಯಸಬಹುದು ಎಂದು ಊಹಿಸುವುದು ಕಷ್ಟವೇನಲ್ಲ. ಅವರು ಮೆಟ್ಟಿಲುಗಳ ಕೆಳಗೆ ಇಳಿದು ಏನಾಯಿತು ಎಂದು ನೌಕರರನ್ನು ಕೇಳಲು ಪ್ರಾರಂಭಿಸಿದರು. ನಿಸ್ಸಂಶಯವಾಗಿ, ಸಿಸ್ಟಮ್ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದೆ. ಅವರು ಅದನ್ನು ಆಫ್ ಮತ್ತು ಆನ್ ಮಾಡಿದರು, ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡಿದೆ. ಆದರೆ 10 ನಿಮಿಷಗಳ ನಂತರ ವ್ಯವಸ್ಥೆಯು ಕುಸಿಯಿತು.

ಈ ಕ್ಷಣದಲ್ಲಿ ಅಂತಹದ್ದೇ ಏನೋ ಸಂಭವಿಸಿದೆ. ಇದ್ದಕ್ಕಿದ್ದಂತೆ, ಟಿಕೆಟ್ ವ್ಯವಸ್ಥೆಯು ದೋಷಗಳನ್ನು ಎಸೆಯಲು ಪ್ರಾರಂಭಿಸಿತು. ಸಿಬ್ಬಂದಿ ನಿಟ್ಟುಸಿರು ಬಿಟ್ಟರು ಮತ್ತು ಪೇಪರ್ ಟಿಕೆಟ್‌ಗಳನ್ನು ಹಿಡಿದುಕೊಂಡರು, ಮತ್ತು ಜೇಮ್ಸ್ ಸರ್ವರ್ ರೂಮ್‌ಗೆ ಧಾವಿಸಿದರು. ಸರ್ವರ್‌ನೊಂದಿಗೆ ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿ ಕಾಣುತ್ತದೆ.

ಆಗ ಒಬ್ಬ ಉದ್ಯೋಗಿ ಒಳಗೆ ಬಂದ.

- ಸಿಸ್ಟಮ್ ಮತ್ತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ.

ಜೇಮ್ಸ್ ಏನನ್ನೂ ಮಾಡದ ಕಾರಣ ಗೊಂದಲಕ್ಕೊಳಗಾದನು. ಹೆಚ್ಚು ನಿಖರವಾಗಿ, ಸಿಸ್ಟಮ್ ಕೆಲಸ ಮಾಡಲು ಏನೂ ಇಲ್ಲ. ಅವರು ಲಾಗ್ ಔಟ್ ಮಾಡಿದರು, ಅವರ ಫೋನ್ ಅನ್ನು ಎತ್ತಿಕೊಂಡರು ಮತ್ತು ಅವರ ಕಂಪನಿಯ ಬೆಂಬಲ ಲೈನ್‌ಗೆ ಕರೆ ಮಾಡಿದರು. ಶೀಘ್ರದಲ್ಲೇ ಅದೇ ಉದ್ಯೋಗಿ ಸರ್ವರ್ ಕೊಠಡಿಯನ್ನು ಪ್ರವೇಶಿಸಿದ.

- ಸಿಸ್ಟಮ್ ಡೌನ್ ಆಗಿದೆ.

ಜೇಮ್ಸ್ ಸರ್ವರ್‌ನತ್ತ ಕಣ್ಣು ಹಾಯಿಸಿದ. ಬಹು-ಬಣ್ಣದ ಆಕಾರಗಳ ಆಸಕ್ತಿದಾಯಕ ಮತ್ತು ಪರಿಚಿತ ಮಾದರಿಯು ಪರದೆಯ ಮೇಲೆ ನೃತ್ಯ ಮಾಡಿತು - ಅಸ್ತವ್ಯಸ್ತವಾಗಿ ಸುತ್ತುವ ಮತ್ತು ಹೆಣೆದುಕೊಂಡಿರುವ ಕೊಳವೆಗಳು. ನಾವೆಲ್ಲರೂ ಈ ಸ್ಕ್ರೀನ್‌ಸೇವರ್ ಅನ್ನು ಕೆಲವು ಹಂತದಲ್ಲಿ ನೋಡಿದ್ದೇವೆ. ಇದು ಸುಂದರವಾಗಿ ನಿರೂಪಿಸಲ್ಪಟ್ಟಿದೆ ಮತ್ತು ಅಕ್ಷರಶಃ ಸಂಮೋಹನಗೊಳಿಸಿತು.

ಜೇಮ್ಸ್ ಒಂದು ಗುಂಡಿಯನ್ನು ಒತ್ತಿದರೆ ಮತ್ತು ಮಾದರಿಯು ಕಣ್ಮರೆಯಾಯಿತು. ಅವರು ಟಿಕೆಟ್ ಕಛೇರಿಗೆ ಆತುರದಿಂದ ಹೋದರು ಮತ್ತು ದಾರಿಯಲ್ಲಿ ಅವನ ಬಳಿಗೆ ಹಿಂದಿರುಗುವ ಉದ್ಯೋಗಿಯನ್ನು ಭೇಟಿಯಾದರು.

- ಸಿಸ್ಟಮ್ ಮತ್ತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ.

ನೀವು ಮಾನಸಿಕ ಮುಖವನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಾದರೆ, ಜೇಮ್ಸ್ ಮಾಡಿದ್ದು ಅದನ್ನೇ. ಸ್ಕ್ರೀನ್ ಸೇವರ್. ಇದು OpenGL ಅನ್ನು ಬಳಸುತ್ತದೆ. ಮತ್ತು ಆದ್ದರಿಂದ, ಕಾರ್ಯಾಚರಣೆಯ ಸಮಯದಲ್ಲಿ, ಇದು ಸರ್ವರ್ ಪ್ರೊಸೆಸರ್ನ ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, ಸರ್ವರ್‌ಗೆ ಪ್ರತಿ ಕರೆಯು ಕಾಲಾವಧಿಯೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ.

ಜೇಮ್ಸ್ ಸರ್ವರ್ ಕೋಣೆಗೆ ಹಿಂದಿರುಗಿದನು, ಲಾಗ್ ಇನ್ ಮಾಡಿದನು ಮತ್ತು ಖಾಲಿ ಪರದೆಯೊಂದಿಗೆ ಸುಂದರವಾದ ಪೈಪ್‌ಗಳೊಂದಿಗೆ ಸ್ಕ್ರೀನ್‌ಸೇವರ್ ಅನ್ನು ಬದಲಾಯಿಸಿದನು. ಅಂದರೆ, 100% ಪ್ರೊಸೆಸರ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸೇವಿಸುವ ಸ್ಕ್ರೀನ್ ಸೇವರ್ ಬದಲಿಗೆ, ನಾನು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸೇವಿಸದ ಇನ್ನೊಂದನ್ನು ಸ್ಥಾಪಿಸಿದೆ. ನಂತರ ನನ್ನ ಊಹೆಯನ್ನು ಪರಿಶೀಲಿಸಲು ನಾನು 10 ನಿಮಿಷ ಕಾಯುತ್ತಿದ್ದೆ.

ಜೇಮ್ಸ್ ಮುಂದಿನ ಚಿತ್ರಮಂದಿರಕ್ಕೆ ಬಂದಾಗ, ಅವನು ತನ್ನ ಮ್ಯಾನೇಜರ್‌ಗೆ ಹೇಗೆ ವಿವರಿಸಬೇಕೆಂದು ಯೋಚಿಸುತ್ತಿದ್ದನು, ಅವನು ಸ್ಕ್ರೀನ್ ಸೇವರ್ ಅನ್ನು ಆಫ್ ಮಾಡಲು 800 ಕಿ.ಮೀ.

ಚಂದ್ರನ ಒಂದು ನಿರ್ದಿಷ್ಟ ಹಂತದಲ್ಲಿ ಕ್ರ್ಯಾಶ್

ಸತ್ಯ ಕಥೆ. ಒಂದು ದಿನ ಚಂದ್ರನ ಹಂತವನ್ನು ಅವಲಂಬಿಸಿರುವ ಸಾಫ್ಟ್‌ವೇರ್ ದೋಷವು ಹುಟ್ಟಿಕೊಂಡಿತು. ಚಂದ್ರನ ನಿಜವಾದ ಹಂತಕ್ಕೆ ಅಂದಾಜು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ವಿವಿಧ MIT ಕಾರ್ಯಕ್ರಮಗಳಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ ಬಳಸಲಾಗುವ ಸ್ವಲ್ಪ ದಿನಚರಿ ಇತ್ತು. GLS ಈ ದಿನಚರಿಯನ್ನು LISP ಪ್ರೋಗ್ರಾಂ ಆಗಿ ನಿರ್ಮಿಸಿದೆ, ಅದು ಫೈಲ್ ಅನ್ನು ಬರೆಯುವಾಗ, ಸುಮಾರು 80 ಅಕ್ಷರಗಳ ಸಮಯಸ್ಟ್ಯಾಂಪ್‌ನೊಂದಿಗೆ ಸಾಲನ್ನು ಔಟ್‌ಪುಟ್ ಮಾಡುತ್ತದೆ. ಸಂದೇಶದ ಮೊದಲ ಸಾಲು ತುಂಬಾ ಉದ್ದವಾಗಿದೆ ಮತ್ತು ಮುಂದಿನ ಸಾಲಿಗೆ ಕಾರಣವಾಗುವುದು ಬಹಳ ಅಪರೂಪ. ಮತ್ತು ಪ್ರೋಗ್ರಾಂ ನಂತರ ಈ ಫೈಲ್ ಅನ್ನು ಓದಿದಾಗ, ಅದು ಶಾಪವಾಯಿತು. ಮೊದಲ ಸಾಲಿನ ಉದ್ದವು ನಿಖರವಾದ ದಿನಾಂಕ ಮತ್ತು ಸಮಯವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ, ಹಾಗೆಯೇ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ ಅನ್ನು ಮುದ್ರಿಸಿದ ಸಮಯದಲ್ಲಿ ಹಂತದ ವಿವರಣೆಯ ಉದ್ದವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಅಂದರೆ, ದೋಷವು ಅಕ್ಷರಶಃ ಚಂದ್ರನ ಹಂತವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ!

ಮೊದಲ ಕಾಗದದ ಆವೃತ್ತಿ ಪರಿಭಾಷೆ ಫೈಲ್ (ಸ್ಟೀಲ್-1983) ವಿವರಿಸಿದ ದೋಷಕ್ಕೆ ಕಾರಣವಾದ ಅಂತಹ ರೇಖೆಯ ಉದಾಹರಣೆಯನ್ನು ಒಳಗೊಂಡಿದೆ, ಆದರೆ ಟೈಪ್‌ಸೆಟರ್ ಅದನ್ನು "ಸರಿಪಡಿಸಿದೆ". ಅಂದಿನಿಂದ ಇದನ್ನು "ಚಂದ್ರನ ಹಂತದ ದೋಷ" ಎಂದು ವಿವರಿಸಲಾಗಿದೆ.

ಆದಾಗ್ಯೂ, ಊಹೆಗಳೊಂದಿಗೆ ಜಾಗರೂಕರಾಗಿರಿ. ಕೆಲವು ವರ್ಷಗಳ ಹಿಂದೆ, CERN (ಯುರೋಪಿಯನ್ ಸೆಂಟರ್ ಫಾರ್ ನ್ಯೂಕ್ಲಿಯರ್ ರಿಸರ್ಚ್) ಇಂಜಿನಿಯರ್‌ಗಳು ದೊಡ್ಡ ಎಲೆಕ್ಟ್ರಾನ್-ಪಾಸಿಟ್ರಾನ್ ಕೊಲೈಡರ್‌ನಲ್ಲಿ ನಡೆಸಿದ ಪ್ರಯೋಗಗಳಲ್ಲಿ ದೋಷಗಳನ್ನು ಎದುರಿಸಿದರು. ವಿಜ್ಞಾನಿಗಳಿಗೆ ಫಲಿತಾಂಶವನ್ನು ತೋರಿಸುವ ಮೊದಲು ಕಂಪ್ಯೂಟರ್‌ಗಳು ಈ ಸಾಧನದಿಂದ ಉತ್ಪತ್ತಿಯಾಗುವ ಅಗಾಧ ಪ್ರಮಾಣದ ಡೇಟಾವನ್ನು ಸಕ್ರಿಯವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದರಿಂದ, ಸಾಫ್ಟ್‌ವೇರ್ ಚಂದ್ರನ ಹಂತಕ್ಕೆ ಹೇಗಾದರೂ ಸೂಕ್ಷ್ಮವಾಗಿರುತ್ತದೆ ಎಂದು ಹಲವರು ಊಹಿಸಿದ್ದಾರೆ. ಹಲವಾರು ಹತಾಶ ಎಂಜಿನಿಯರ್‌ಗಳು ಸತ್ಯದ ಕೆಳಭಾಗಕ್ಕೆ ಬಂದರು. ಚಂದ್ರನ ಅಂಗೀಕಾರದ ಸಮಯದಲ್ಲಿ ಭೂಮಿಯ ವಿರೂಪದಿಂದಾಗಿ 27 ಕಿಮೀ ಉದ್ದದ ಉಂಗುರದ ರೇಖಾಗಣಿತದಲ್ಲಿ ಸ್ವಲ್ಪ ಬದಲಾವಣೆಯಿಂದಾಗಿ ದೋಷ ಉದ್ಭವಿಸಿದೆ! ಈ ಕಥೆಯು ಭೌತಶಾಸ್ತ್ರದ ಜಾನಪದವನ್ನು "ಕಣ ಭೌತಶಾಸ್ತ್ರದ ಮೇಲೆ ನ್ಯೂಟನ್ರ ಪ್ರತೀಕಾರ" ಎಂದು ನಮೂದಿಸಿದೆ ಮತ್ತು ಭೌತಶಾಸ್ತ್ರದ ಸರಳ ಮತ್ತು ಹಳೆಯ ನಿಯಮಗಳು ಮತ್ತು ಅತ್ಯಾಧುನಿಕ ವೈಜ್ಞಾನಿಕ ಪರಿಕಲ್ಪನೆಗಳ ನಡುವಿನ ಸಂಪರ್ಕದ ಉದಾಹರಣೆಯಾಗಿದೆ.

ಶೌಚಾಲಯವನ್ನು ಫ್ಲಶ್ ಮಾಡುವುದರಿಂದ ರೈಲು ನಿಲ್ಲುತ್ತದೆ

ನಾನು ಕೇಳಿದ ಅತ್ಯುತ್ತಮ ಹಾರ್ಡ್‌ವೇರ್ ದೋಷವೆಂದರೆ ಫ್ರಾನ್ಸ್‌ನ ಹೈ ಸ್ಪೀಡ್ ರೈಲಿನಲ್ಲಿ. ದೋಷವು ರೈಲಿನ ತುರ್ತು ಬ್ರೇಕಿಂಗ್‌ಗೆ ಕಾರಣವಾಯಿತು, ಆದರೆ ಹಡಗಿನಲ್ಲಿ ಪ್ರಯಾಣಿಕರಿದ್ದರೆ ಮಾತ್ರ. ಅಂತಹ ಪ್ರತಿಯೊಂದು ಪ್ರಕರಣದಲ್ಲಿ, ರೈಲನ್ನು ಸೇವೆಯಿಂದ ತೆಗೆದುಹಾಕಲಾಯಿತು, ಪರಿಶೀಲಿಸಲಾಯಿತು, ಆದರೆ ಏನೂ ಕಂಡುಬಂದಿಲ್ಲ. ನಂತರ ಅವರನ್ನು ಮರಳಿ ಸಾಲಿಗೆ ಕಳುಹಿಸಲಾಯಿತು, ಮತ್ತು ಅವರು ತಕ್ಷಣವೇ ನಿಲುಗಡೆಗೆ ಅಪ್ಪಳಿಸಿದರು.

ತಪಾಸಣೆಯ ಸಮಯದಲ್ಲಿ, ರೈಲಿನಲ್ಲಿ ಪ್ರಯಾಣಿಸುತ್ತಿದ್ದ ಇಂಜಿನಿಯರ್ ಶೌಚಾಲಯಕ್ಕೆ ಹೋದರು. ಅವರು ಶೀಘ್ರದಲ್ಲೇ ಕೊಚ್ಚಿಕೊಂಡು ಹೋದರು, ಬೂಮ್! ತುರ್ತು ನಿಲುಗಡೆ.

ಇಂಜಿನಿಯರ್ ಚಾಲಕನನ್ನು ಸಂಪರ್ಕಿಸಿ ಕೇಳಿದರು:

- ಬ್ರೇಕ್ ಮಾಡುವ ಮೊದಲು ನೀವು ಏನು ಮಾಡುತ್ತಿದ್ದೀರಿ?

- ಸರಿ, ನಾನು ಅವರೋಹಣವನ್ನು ನಿಧಾನಗೊಳಿಸಿದೆ ...

ಇದು ವಿಚಿತ್ರವಾಗಿತ್ತು, ಏಕೆಂದರೆ ಸಾಮಾನ್ಯ ಕಾರ್ಯಾಚರಣೆಯ ಸಮಯದಲ್ಲಿ ರೈಲು ಹತ್ತಾರು ಬಾರಿ ಅವರೋಹಣವನ್ನು ನಿಧಾನಗೊಳಿಸುತ್ತದೆ. ರೈಲು ಚಲಿಸಿತು, ಮತ್ತು ಮುಂದಿನ ಇಳಿಜಾರಿನಲ್ಲಿ ಚಾಲಕನು ಎಚ್ಚರಿಸಿದನು:

- ನಾನು ನಿಧಾನವಾಗಿ ಹೋಗುತ್ತೇನೆ.

ಏನೂ ಆಗಲಿಲ್ಲ.

- ಕೊನೆಯ ಬ್ರೇಕಿಂಗ್ ಸಮಯದಲ್ಲಿ ನೀವು ಏನು ಮಾಡಿದ್ದೀರಿ? - ಚಾಲಕ ಕೇಳಿದರು.

- ಸರಿ ... ನಾನು ಶೌಚಾಲಯದಲ್ಲಿದ್ದೆ ...

- ಸರಿ, ನಂತರ ಶೌಚಾಲಯಕ್ಕೆ ಹೋಗಿ ಮತ್ತು ನಾವು ಮತ್ತೆ ಕೆಳಗೆ ಹೋದಾಗ ನೀವು ಮಾಡಿದ್ದನ್ನು ಮಾಡಿ!

ಇಂಜಿನಿಯರ್ ಟಾಯ್ಲೆಟ್ಗೆ ಹೋದರು, ಮತ್ತು ಚಾಲಕ ಎಚ್ಚರಿಸಿದಾಗ: "ನಾನು ನಿಧಾನಗೊಳಿಸುತ್ತಿದ್ದೇನೆ," ಅವರು ನೀರನ್ನು ತೊಳೆಯುತ್ತಾರೆ. ಸಹಜವಾಗಿ, ರೈಲು ತಕ್ಷಣ ನಿಂತಿತು.

ಈಗ ಅವರು ಸಮಸ್ಯೆಯನ್ನು ಪುನರುತ್ಪಾದಿಸಬಹುದು ಮತ್ತು ಕಾರಣವನ್ನು ಕಂಡುಹಿಡಿಯಬೇಕು.

ಎರಡು ನಿಮಿಷಗಳ ನಂತರ, ಎಂಜಿನ್ ಬ್ರೇಕ್ ರಿಮೋಟ್ ಕಂಟ್ರೋಲ್ ಕೇಬಲ್ (ರೈಲು ಪ್ರತಿ ತುದಿಯಲ್ಲಿ ಒಂದು ಎಂಜಿನ್ ಹೊಂದಿತ್ತು) ವಿದ್ಯುತ್ ಕ್ಯಾಬಿನೆಟ್ನ ಗೋಡೆಯಿಂದ ಸಂಪರ್ಕ ಕಡಿತಗೊಂಡಿದೆ ಮತ್ತು ಟಾಯ್ಲೆಟ್ ಪ್ಲಗ್ ಸೊಲೆನಾಯ್ಡ್ ಅನ್ನು ನಿಯಂತ್ರಿಸುವ ರಿಲೇ ಮೇಲೆ ಮಲಗಿರುವುದನ್ನು ಅವರು ಗಮನಿಸಿದರು ... ರಿಲೇ ಯಾವಾಗ ಆನ್ ಮಾಡಲಾಗಿದೆ, ಇದು ಬ್ರೇಕ್ ಕೇಬಲ್‌ನಲ್ಲಿ ಹಸ್ತಕ್ಷೇಪವನ್ನು ಸೃಷ್ಟಿಸಿತು ಮತ್ತು ವೈಫಲ್ಯಗಳ ವಿರುದ್ಧ ಸಿಸ್ಟಮ್ ರಕ್ಷಣೆಯು ತುರ್ತು ಬ್ರೇಕಿಂಗ್ ಅನ್ನು ಒಳಗೊಂಡಿದೆ.

ಫೋರ್ಟ್ರಾನ್ ಅನ್ನು ದ್ವೇಷಿಸುವ ಗೇಟ್‌ವೇ

ಕೆಲವು ತಿಂಗಳುಗಳ ಹಿಂದೆ ಮುಖ್ಯ ಭೂಭಾಗದ [ಇದು ಹವಾಯಿಯಲ್ಲಿ] ನೆಟ್‌ವರ್ಕ್ ಸಂಪರ್ಕಗಳು ತುಂಬಾ ನಿಧಾನವಾಗುತ್ತಿರುವುದನ್ನು ನಾವು ಗಮನಿಸಿದ್ದೇವೆ. ಇದು 10-15 ನಿಮಿಷಗಳವರೆಗೆ ಇರುತ್ತದೆ ಮತ್ತು ನಂತರ ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಮತ್ತೆ ಸಂಭವಿಸಬಹುದು. ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ, ನನ್ನ ಸಹೋದ್ಯೋಗಿ ಮುಖ್ಯಭೂಮಿಯಲ್ಲಿ ನೆಟ್ವರ್ಕ್ ಸಂಪರ್ಕಗಳನ್ನು ನನಗೆ ದೂರಿದರು ಸಾಮಾನ್ಯವಾಗಿ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ. ಅವರು ಕೆಲವು ಫೋರ್ಟ್ರಾನ್ ಕೋಡ್ ಅನ್ನು ಹೊಂದಿದ್ದರು, ಅದನ್ನು ಮುಖ್ಯ ಭೂಭಾಗದಲ್ಲಿರುವ ಯಂತ್ರಕ್ಕೆ ನಕಲಿಸಬೇಕಾಗಿದೆ, ಆದರೆ ಅದು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ ಏಕೆಂದರೆ "ಎಫ್‌ಟಿಪಿ ಅಪ್‌ಲೋಡ್ ಪೂರ್ಣಗೊಳ್ಳಲು ನೆಟ್‌ವರ್ಕ್ ಸಾಕಷ್ಟು ಸಮಯ ಹಿಡಿದಿಲ್ಲ."

ಹೌದು, ಸಹೋದ್ಯೋಗಿಯೊಬ್ಬರು ಫೋರ್ಟ್ರಾನ್‌ನಲ್ಲಿನ ಮೂಲ ಕೋಡ್ ಹೊಂದಿರುವ ಫೈಲ್ ಅನ್ನು ಮುಖ್ಯ ಭೂಭಾಗದಲ್ಲಿರುವ ಯಂತ್ರಕ್ಕೆ FTP ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದಾಗ ನೆಟ್‌ವರ್ಕ್ ವೈಫಲ್ಯಗಳು ಸಂಭವಿಸಿವೆ ಎಂದು ತಿಳಿದುಬಂದಿದೆ. ನಾವು ಫೈಲ್ ಅನ್ನು ಆರ್ಕೈವ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ: ನಂತರ ಅದನ್ನು ಸಲೀಸಾಗಿ ನಕಲಿಸಲಾಗಿದೆ (ಆದರೆ ಗುರಿ ಯಂತ್ರವು ಅನ್ಪ್ಯಾಕರ್ ಅನ್ನು ಹೊಂದಿಲ್ಲ, ಆದ್ದರಿಂದ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲಾಗಿಲ್ಲ). ಅಂತಿಮವಾಗಿ ನಾವು ಫೋರ್ಟ್ರಾನ್ ಕೋಡ್ ಅನ್ನು "ವಿಭಜಿಸಿ" ಸಣ್ಣ ತುಂಡುಗಳಾಗಿ ಮತ್ತು ಅವುಗಳನ್ನು ಒಂದೊಂದಾಗಿ ಕಳುಹಿಸಿದ್ದೇವೆ. ಹೆಚ್ಚಿನ ತುಣುಕುಗಳನ್ನು ಸಮಸ್ಯೆಗಳಿಲ್ಲದೆ ನಕಲಿಸಲಾಗಿದೆ, ಆದರೆ ಕೆಲವು ತುಣುಕುಗಳು ಹಾದುಹೋಗಲಿಲ್ಲ ಅಥವಾ ನಂತರ ಹಾದು ಹೋಗಲಿಲ್ಲ ಹಲವಾರು ಪ್ರಯತ್ನಗಳು.

ನಾವು ಸಮಸ್ಯಾತ್ಮಕ ಹಾದಿಗಳನ್ನು ಪರಿಶೀಲಿಸಿದಾಗ, ಅವುಗಳು ಸಾಮಾನ್ಯವಾದದ್ದನ್ನು ಹೊಂದಿವೆ ಎಂದು ನಾವು ಕಂಡುಹಿಡಿದಿದ್ದೇವೆ: ಅವೆಲ್ಲವೂ ಕ್ಯಾಪಿಟಲ್ C ಅನ್ನು ಒಳಗೊಂಡಿರುವ ಸಾಲುಗಳೊಂದಿಗೆ ಪ್ರಾರಂಭವಾದ ಮತ್ತು ಕೊನೆಗೊಳ್ಳುವ ಕಾಮೆಂಟ್ ಬ್ಲಾಕ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿವೆ (ಸಹೋದ್ಯೋಗಿಯು ಫೋರ್ಟ್ರಾನ್‌ನಲ್ಲಿ ಕಾಮೆಂಟ್ ಮಾಡಲು ಆದ್ಯತೆ ನೀಡಿದಂತೆ). ನಾವು ಮುಖ್ಯ ಭೂಭಾಗದಲ್ಲಿರುವ ನೆಟ್‌ವರ್ಕ್ ತಜ್ಞರಿಗೆ ಇಮೇಲ್ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಸಹಾಯಕ್ಕಾಗಿ ಕೇಳಿದ್ದೇವೆ. ಸಹಜವಾಗಿ, ಅವರು ಎಫ್‌ಟಿಪಿ ಮೂಲಕ ವರ್ಗಾಯಿಸಲಾಗದ ನಮ್ಮ ಫೈಲ್‌ಗಳ ಮಾದರಿಗಳನ್ನು ನೋಡಲು ಬಯಸಿದ್ದರು... ಆದರೆ ನಮ್ಮ ಪತ್ರಗಳು ಅವರನ್ನು ತಲುಪಲಿಲ್ಲ. ಅಂತಿಮವಾಗಿ ನಾವು ಸರಳವಾದ ವಿಷಯದೊಂದಿಗೆ ಬಂದಿದ್ದೇವೆ ವಿವರಿಸಿವರ್ಗಾಯಿಸಲಾಗದ ಫೈಲ್‌ಗಳು ಹೇಗಿರುತ್ತವೆ. ಇದು ಕೆಲಸ ಮಾಡಿದೆ :) [ಇಲ್ಲಿ ಸಮಸ್ಯಾತ್ಮಕ ಫೋರ್ಟ್ರಾನ್ ಕಾಮೆಂಟ್‌ಗಳ ಉದಾಹರಣೆಯನ್ನು ಸೇರಿಸಲು ಧೈರ್ಯವಿದೆಯೇ? ಬಹುಶಃ ಇದು ಯೋಗ್ಯವಾಗಿಲ್ಲ!]

ಕೊನೆಯಲ್ಲಿ ನಾವು ಅದನ್ನು ಕಂಡುಹಿಡಿಯುವಲ್ಲಿ ಯಶಸ್ವಿಯಾಗಿದ್ದೇವೆ. ಕ್ಯಾಂಪಸ್‌ನ ನಮ್ಮ ಭಾಗ ಮತ್ತು ಮುಖ್ಯ ಭೂಭಾಗದ ನೆಟ್‌ವರ್ಕ್ ನಡುವೆ ಹೊಸ ಗೇಟ್‌ವೇ ಅನ್ನು ಇತ್ತೀಚೆಗೆ ಸ್ಥಾಪಿಸಲಾಗಿದೆ. ದೊಡ್ಡಕ್ಷರ C ಯ ಪುನರಾವರ್ತಿತ ಬಿಟ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುವ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ರವಾನಿಸಲು ಇದು ದೊಡ್ಡ ಕಷ್ಟವನ್ನು ಹೊಂದಿತ್ತು! ಈ ಕೆಲವು ಪ್ಯಾಕೆಟ್‌ಗಳು ಎಲ್ಲಾ ಗೇಟ್‌ವೇ ಸಂಪನ್ಮೂಲಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು ಮತ್ತು ಇತರ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಪ್ರವೇಶಿಸದಂತೆ ತಡೆಯಬಹುದು. ನಾವು ಗೇಟ್‌ವೇ ತಯಾರಕರಿಗೆ ದೂರು ನೀಡಿದ್ದೇವೆ ... ಮತ್ತು ಅವರು ಉತ್ತರಿಸಿದರು: “ಓಹ್, ಹೌದು, ನೀವು ಪುನರಾವರ್ತಿತ C ಯ ದೋಷವನ್ನು ಎದುರಿಸುತ್ತಿರುವಿರಿ! ಅವನ ಬಗ್ಗೆ ನಮಗೆ ಈಗಾಗಲೇ ತಿಳಿದಿದೆ. ” ನಾವು ಅಂತಿಮವಾಗಿ ಮತ್ತೊಂದು ತಯಾರಕರಿಂದ ಹೊಸ ಗೇಟ್‌ವೇ ಖರೀದಿಸುವ ಮೂಲಕ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಿದ್ದೇವೆ (ಮೊದಲಿನ ರಕ್ಷಣೆಯಲ್ಲಿ, FORTRAN ಕಾರ್ಯಕ್ರಮಗಳನ್ನು ವರ್ಗಾಯಿಸಲು ಅಸಮರ್ಥತೆಯು ಕೆಲವರಿಗೆ ಅನುಕೂಲವಾಗಬಹುದು!).

ಕಠಿಣ ಸಮಯ

ಕೆಲವು ವರ್ಷಗಳ ಹಿಂದೆ, ಹಂತ 40 ಕ್ಲಿನಿಕಲ್ ಪ್ರಯೋಗಗಳ ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಪರ್ಲ್‌ನಲ್ಲಿ ETL ವ್ಯವಸ್ಥೆಯನ್ನು ರಚಿಸುವ ಕೆಲಸ ಮಾಡುವಾಗ, ನಾನು ಸುಮಾರು 000 ದಿನಾಂಕಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬೇಕಾಗಿತ್ತು. ಅವರಲ್ಲಿ ಇಬ್ಬರು ಪರೀಕ್ಷೆಯಲ್ಲಿ ಉತ್ತೀರ್ಣರಾಗಲಿಲ್ಲ. ಇದು ನನಗೆ ತುಂಬಾ ತೊಂದರೆಯಾಗಲಿಲ್ಲ ಏಕೆಂದರೆ ಈ ದಿನಾಂಕಗಳನ್ನು ಕ್ಲೈಂಟ್-ಒದಗಿಸಿದ ಡೇಟಾದಿಂದ ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ, ಅದು ಸಾಮಾನ್ಯವಾಗಿ ಆಶ್ಚರ್ಯಕರವಾಗಿದೆ. ಆದರೆ ನಾನು ಮೂಲ ಡೇಟಾವನ್ನು ಪರಿಶೀಲಿಸಿದಾಗ, ಈ ದಿನಾಂಕಗಳು ಜನವರಿ 1, 2011 ಮತ್ತು ಜನವರಿ 1, 2007 ಎಂದು ಬದಲಾಯಿತು. ನಾನು ಬರೆದ ಪ್ರೋಗ್ರಾಂನಲ್ಲಿ ದೋಷವು ಇದೆ ಎಂದು ನಾನು ಭಾವಿಸಿದೆ, ಆದರೆ ಅದು ಈಗಾಗಲೇ 30 ವರ್ಷಗಳು ಎಂದು ಬದಲಾಯಿತು. ಹಳೆಯದು. ಸಾಫ್ಟ್‌ವೇರ್ ಪರಿಸರ ವ್ಯವಸ್ಥೆಯ ಪರಿಚಯವಿಲ್ಲದವರಿಗೆ ಇದು ನಿಗೂಢವಾಗಿ ತೋರುತ್ತದೆ. ಮತ್ತೊಂದು ಕಂಪನಿಯು ಹಣ ಗಳಿಸುವ ದೀರ್ಘಾವಧಿಯ ನಿರ್ಧಾರದಿಂದಾಗಿ, ಒಂದು ಕಂಪನಿಯು ಆಕಸ್ಮಿಕವಾಗಿ ಮತ್ತು ಇನ್ನೊಂದು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಪರಿಚಯಿಸಿದ ದೋಷವನ್ನು ಸರಿಪಡಿಸಲು ನನ್ನ ಕ್ಲೈಂಟ್ ನನಗೆ ಪಾವತಿಸಿದೆ. ನಾನು ಏನು ಮಾತನಾಡುತ್ತಿದ್ದೇನೆ ಎಂಬುದನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ನಾನು ದೋಷವಾಗಿ ಕೊನೆಗೊಂಡ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಸೇರಿಸಿದ ಕಂಪನಿಯ ಬಗ್ಗೆ ಮಾತನಾಡಬೇಕಾಗಿದೆ, ಜೊತೆಗೆ ನಾನು ಸರಿಪಡಿಸಿದ ನಿಗೂಢ ದೋಷಕ್ಕೆ ಕಾರಣವಾದ ಕೆಲವು ಇತರ ಆಸಕ್ತಿದಾಯಕ ಘಟನೆಗಳು.

ಉತ್ತಮ ಹಳೆಯ ದಿನಗಳಲ್ಲಿ, ಆಪಲ್ ಕಂಪ್ಯೂಟರ್‌ಗಳು ಕೆಲವೊಮ್ಮೆ ತಮ್ಮ ದಿನಾಂಕವನ್ನು ಜನವರಿ 1, 1904 ಕ್ಕೆ ಸ್ವಯಂಪ್ರೇರಿತವಾಗಿ ಮರುಹೊಂದಿಸುತ್ತವೆ. ಕಾರಣ ಸರಳವಾಗಿತ್ತು: ಇದು ದಿನಾಂಕ ಮತ್ತು ಸಮಯವನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಬ್ಯಾಟರಿ ಚಾಲಿತ "ಸಿಸ್ಟಮ್ ಗಡಿಯಾರ" ಅನ್ನು ಬಳಸಿದೆ. ಬ್ಯಾಟರಿ ಸತ್ತಾಗ ಏನಾಯಿತು? ಒಂದು ಯುಗದ ಆರಂಭದಿಂದಲೂ ಕಂಪ್ಯೂಟರ್‌ಗಳು ದಿನಾಂಕವನ್ನು ಸೆಕೆಂಡುಗಳ ಸಂಖ್ಯೆಯಿಂದ ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದವು. ಯುಗದಿಂದ ನಾವು ಉಲ್ಲೇಖದ ಮೂಲ ದಿನಾಂಕವನ್ನು ಅರ್ಥೈಸಿದ್ದೇವೆ ಮತ್ತು ಮ್ಯಾಕಿಂತೋಷ್‌ಗಳಿಗೆ ಅದು ಜನವರಿ 1, 1904 ಆಗಿತ್ತು. ಮತ್ತು ಬ್ಯಾಟರಿ ಸತ್ತ ನಂತರ, ಪ್ರಸ್ತುತ ದಿನಾಂಕವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ದಿನಾಂಕಕ್ಕೆ ಮರುಹೊಂದಿಸಲಾಗಿದೆ. ಆದರೆ ಇದು ಏಕೆ ಸಂಭವಿಸಿತು?

ಹಿಂದೆ, ಆಪಲ್ ಮೂಲ ದಿನಾಂಕದಿಂದ ಸೆಕೆಂಡುಗಳ ಸಂಖ್ಯೆಯನ್ನು ಸಂಗ್ರಹಿಸಲು 32 ಬಿಟ್‌ಗಳನ್ನು ಬಳಸಿತು. ಒಂದು ಬಿಟ್ ಎರಡು ಮೌಲ್ಯಗಳಲ್ಲಿ ಒಂದನ್ನು ಸಂಗ್ರಹಿಸಬಹುದು - 1 ಅಥವಾ 0. ಎರಡು ಬಿಟ್‌ಗಳು ನಾಲ್ಕು ಮೌಲ್ಯಗಳಲ್ಲಿ ಒಂದನ್ನು ಸಂಗ್ರಹಿಸಬಹುದು: 00, 01, 10, 11. ಮೂರು ಬಿಟ್‌ಗಳು - ಎಂಟರಲ್ಲಿ ಒಂದು ಮೌಲ್ಯ: 000, 001, 010, 011, 100 , 101, 110, 111, ಇತ್ಯಾದಿ. ಮತ್ತು 32 232 ಮೌಲ್ಯಗಳಲ್ಲಿ ಒಂದನ್ನು ಸಂಗ್ರಹಿಸಬಹುದು, ಅಂದರೆ 4 ಸೆಕೆಂಡುಗಳು. ಆಪಲ್ ದಿನಾಂಕಗಳಿಗಾಗಿ, ಇದು ಸುಮಾರು 294 ವರ್ಷಗಳಿಗೆ ಸಮನಾಗಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಹಳೆಯ ಮ್ಯಾಕ್‌ಗಳು 967 ರ ನಂತರ ದಿನಾಂಕಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಮತ್ತು ಸಿಸ್ಟಮ್ ಬ್ಯಾಟರಿಯು ಸತ್ತರೆ, ಯುಗ ಪ್ರಾರಂಭವಾದಾಗಿನಿಂದ ದಿನಾಂಕವನ್ನು 296 ಸೆಕೆಂಡುಗಳಿಗೆ ಮರುಹೊಂದಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನೀವು ಕಂಪ್ಯೂಟರ್ ಅನ್ನು ಆನ್ ಮಾಡಿದಾಗಲೆಲ್ಲಾ (ಅಥವಾ ನೀವು ಹೊಸ ಬ್ಯಾಟರಿಯನ್ನು ಖರೀದಿಸುವವರೆಗೆ) ನೀವು ದಿನಾಂಕವನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಹೊಂದಿಸಬೇಕು.

ಆದಾಗ್ಯೂ, ಯುಗದಿಂದ ದಿನಾಂಕಗಳನ್ನು ಸೆಕೆಂಡುಗಳಂತೆ ಸಂಗ್ರಹಿಸಲು Apple ನ ನಿರ್ಧಾರವು ನಾವು ನೋಡುವಂತೆ ದೂರಗಾಮಿ ಪರಿಣಾಮಗಳನ್ನು ಹೊಂದಿರುವ ಯುಗಕ್ಕೆ ಮುಂಚಿತವಾಗಿ ದಿನಾಂಕಗಳನ್ನು ನಿಭಾಯಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಆಪಲ್ ಒಂದು ವೈಶಿಷ್ಟ್ಯವನ್ನು ಪರಿಚಯಿಸಿತು, ದೋಷವಲ್ಲ. ಇತರ ವಿಷಯಗಳ ಜೊತೆಗೆ, ಇದರರ್ಥ ಮ್ಯಾಕಿಂತೋಷ್ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ "ಮಿಲೇನಿಯಮ್ ಬಗ್" ನಿಂದ ಪ್ರತಿರಕ್ಷಿತವಾಗಿದೆ (ನಿರ್ಬಂಧಗಳನ್ನು ತಪ್ಪಿಸಲು ತಮ್ಮದೇ ಆದ ದಿನಾಂಕ ವ್ಯವಸ್ಥೆಯನ್ನು ಹೊಂದಿರುವ ಅನೇಕ ಮ್ಯಾಕ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಬಗ್ಗೆ ಹೇಳಲಾಗುವುದಿಲ್ಲ).

ಮುಂದುವರೆಯಿರಿ. ನಾವು Lotus 1-2-3 ಅನ್ನು ಬಳಸಿದ್ದೇವೆ, IBM ನ "ಕಿಲ್ಲರ್ ಅಪ್ಲಿಕೇಶನ್" ಇದು PC ಕ್ರಾಂತಿಯನ್ನು ಪ್ರಾರಂಭಿಸಲು ಸಹಾಯ ಮಾಡಿತು, ಆದರೂ Apple ಕಂಪ್ಯೂಟರ್‌ಗಳು VisiCalc ಅನ್ನು ಹೊಂದಿದ್ದವು, ಇದು ವೈಯಕ್ತಿಕ ಕಂಪ್ಯೂಟರ್ ಅನ್ನು ಯಶಸ್ವಿಗೊಳಿಸಿತು. ನ್ಯಾಯಸಮ್ಮತವಾಗಿ, 1-2-3 ಕಾಣಿಸದಿದ್ದರೆ, PC ಗಳು ಅಷ್ಟೇನೂ ಹೊರಹೋಗುತ್ತಿರಲಿಲ್ಲ ಮತ್ತು ವೈಯಕ್ತಿಕ ಕಂಪ್ಯೂಟರ್‌ಗಳ ಇತಿಹಾಸವು ವಿಭಿನ್ನವಾಗಿ ಅಭಿವೃದ್ಧಿ ಹೊಂದಬಹುದಿತ್ತು. ಲೋಟಸ್ 1-2-3 1900 ಅನ್ನು ಅಧಿಕ ವರ್ಷವೆಂದು ತಪ್ಪಾಗಿ ಪರಿಗಣಿಸಲಾಗಿದೆ. ಮೈಕ್ರೋಸಾಫ್ಟ್ ತನ್ನ ಮೊದಲ ಸ್ಪ್ರೆಡ್‌ಶೀಟ್, ಮಲ್ಟಿಪ್ಲಾನ್ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದಾಗ, ಅದು ಮಾರುಕಟ್ಟೆಯ ಸಣ್ಣ ಪಾಲನ್ನು ವಶಪಡಿಸಿಕೊಂಡಿತು. ಮತ್ತು ಅವರು ಎಕ್ಸೆಲ್ ಯೋಜನೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಅವರು ಲೋಟಸ್ 1-2-3 ರಿಂದ ಸಾಲು ಮತ್ತು ಕಾಲಮ್ ಹೆಸರಿಸುವ ಯೋಜನೆಯನ್ನು ನಕಲಿಸಲು ನಿರ್ಧರಿಸಿದರು, ಆದರೆ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ 1900 ಅನ್ನು ಅಧಿಕ ವರ್ಷವೆಂದು ಪರಿಗಣಿಸುವ ಮೂಲಕ ದೋಷ ಹೊಂದಾಣಿಕೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಿರ್ಧರಿಸಿದರು. ಈ ಸಮಸ್ಯೆ ಇಂದಿಗೂ ಇದೆ. ಅಂದರೆ, 1-2-3 ರಲ್ಲಿ ಇದು ದೋಷವಾಗಿತ್ತು, ಆದರೆ ಎಕ್ಸೆಲ್‌ನಲ್ಲಿ ಇದು ಪ್ರಜ್ಞಾಪೂರ್ವಕ ನಿರ್ಧಾರವಾಗಿದ್ದು, ಎಲ್ಲಾ 1-2-3 ಬಳಕೆದಾರರು ತಪ್ಪಾಗಿದ್ದರೂ ಸಹ ಡೇಟಾವನ್ನು ಬದಲಾಯಿಸದೆ ತಮ್ಮ ಕೋಷ್ಟಕಗಳನ್ನು ಎಕ್ಸೆಲ್‌ಗೆ ಆಮದು ಮಾಡಿಕೊಳ್ಳಬಹುದು ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ.

ಆದರೆ ಇನ್ನೊಂದು ಸಮಸ್ಯೆ ಇತ್ತು. ಮೊದಲಿಗೆ, ಮೈಕ್ರೋಸಾಫ್ಟ್ ಮ್ಯಾಕಿಂತೋಷ್‌ಗಾಗಿ ಎಕ್ಸೆಲ್ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿತು, ಇದು ಜನವರಿ 1, 1904 ರ ಮೊದಲು ದಿನಾಂಕಗಳನ್ನು ಗುರುತಿಸಲಿಲ್ಲ. ಮತ್ತು ಎಕ್ಸೆಲ್‌ನಲ್ಲಿ, ಜನವರಿ 1, 1900 ಅನ್ನು ಯುಗದ ಆರಂಭವೆಂದು ಪರಿಗಣಿಸಲಾಗಿದೆ. ಆದ್ದರಿಂದ, ಅಭಿವರ್ಧಕರು ಬದಲಾವಣೆಯನ್ನು ಮಾಡಿದರು ಇದರಿಂದ ಅವರ ಪ್ರೋಗ್ರಾಂ ಯುಗ ಪ್ರಕಾರವನ್ನು ಗುರುತಿಸುತ್ತದೆ ಮತ್ತು ಬಯಸಿದ ಯುಗಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಮೈಕ್ರೋಸಾಫ್ಟ್ ಈ ಬಗ್ಗೆ ವಿವರಣಾತ್ಮಕ ಲೇಖನವನ್ನು ಸಹ ಬರೆದಿದೆ. ಮತ್ತು ಈ ನಿರ್ಧಾರವು ನನ್ನ ದೋಷಕ್ಕೆ ಕಾರಣವಾಯಿತು.

ನನ್ನ ETL ಸಿಸ್ಟಮ್ ವಿಂಡೋಸ್‌ನಲ್ಲಿ ರಚಿಸಲಾದ ಗ್ರಾಹಕರಿಂದ ಎಕ್ಸೆಲ್ ಸ್ಪ್ರೆಡ್‌ಶೀಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಿದೆ, ಆದರೆ ಮ್ಯಾಕ್‌ನಲ್ಲಿ ಸಹ ರಚಿಸಬಹುದು. ಆದ್ದರಿಂದ, ಕೋಷ್ಟಕದಲ್ಲಿ ಯುಗದ ಆರಂಭವು ಜನವರಿ 1, 1900 ಅಥವಾ ಜನವರಿ 1, 1904 ಆಗಿರಬಹುದು. ಕಂಡುಹಿಡಿಯುವುದು ಹೇಗೆ? ಎಕ್ಸೆಲ್ ಫೈಲ್ ಫಾರ್ಮ್ಯಾಟ್ ಅಗತ್ಯ ಮಾಹಿತಿಯನ್ನು ತೋರಿಸುತ್ತದೆ, ಆದರೆ ನಾನು ಬಳಸಿದ ಪಾರ್ಸರ್ ಅದನ್ನು ತೋರಿಸಲಿಲ್ಲ (ಈಗ ಅದು ಮಾಡುತ್ತದೆ), ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಟೇಬಲ್‌ಗಾಗಿ ಯುಗವು ನಿಮಗೆ ತಿಳಿದಿದೆ ಎಂದು ಭಾವಿಸಲಾಗಿದೆ. ನಾನು ಬಹುಶಃ ಎಕ್ಸೆಲ್ ಬೈನರಿ ಸ್ವರೂಪವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಮತ್ತು ಪಾರ್ಸರ್ ಲೇಖಕರಿಗೆ ಪ್ಯಾಚ್ ಕಳುಹಿಸಲು ಹೆಚ್ಚು ಸಮಯವನ್ನು ಕಳೆಯಬಹುದಿತ್ತು, ಆದರೆ ಕ್ಲೈಂಟ್‌ಗಾಗಿ ನಾನು ಇನ್ನೂ ಹೆಚ್ಚಿನದನ್ನು ಮಾಡಬೇಕಾಗಿತ್ತು, ಆದ್ದರಿಂದ ನಾನು ಯುಗವನ್ನು ನಿರ್ಧರಿಸಲು ತ್ವರಿತವಾಗಿ ಹ್ಯೂರಿಸ್ಟಿಕ್ ಅನ್ನು ಬರೆದಿದ್ದೇನೆ. ಅವಳು ಸರಳವಾಗಿದ್ದಳು.

ಎಕ್ಸೆಲ್ ನಲ್ಲಿ, ದಿನಾಂಕ ಜುಲೈ 5, 1998 ಅನ್ನು "07-05-98" (ಅನುಪಯುಕ್ತ ಅಮೇರಿಕನ್ ವ್ಯವಸ್ಥೆ), "ಜುಲೈ 5, 98", "ಜುಲೈ 5, 1998", "5-ಜುಲೈ-98" ಅಥವಾ ಕೆಲವು ಇತರ ಫಾರ್ಮ್ಯಾಟ್ ಮತ್ತೊಂದು ಅನುಪಯುಕ್ತ ಸ್ವರೂಪ (ವ್ಯಂಗ್ಯವಾಗಿ, ಎಕ್ಸೆಲ್ ನ ನನ್ನ ಆವೃತ್ತಿಯು ನೀಡದ ಸ್ವರೂಪಗಳಲ್ಲಿ ಒಂದು ISO 8601 ಆಗಿತ್ತು). ಆದಾಗ್ಯೂ, ಕೋಷ್ಟಕದಲ್ಲಿ, ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡದ ದಿನಾಂಕವನ್ನು ಯುಗ-35981 ಕ್ಕೆ "1900" ಅಥವಾ ಯುಗ-34519 ಗಾಗಿ "1904" ಎಂದು ಸಂಗ್ರಹಿಸಲಾಗಿದೆ (ಸಂಖ್ಯೆಗಳು ಯುಗದಿಂದ ದಿನಗಳ ಸಂಖ್ಯೆಯನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತವೆ). ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡಿದ ದಿನಾಂಕದಿಂದ ವರ್ಷವನ್ನು ಹೊರತೆಗೆಯಲು ನಾನು ಸರಳವಾದ ಪಾರ್ಸರ್ ಅನ್ನು ಬಳಸಿದ್ದೇನೆ ಮತ್ತು ನಂತರ ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡದ ದಿನಾಂಕದಿಂದ ವರ್ಷವನ್ನು ಹೊರತೆಗೆಯಲು ಎಕ್ಸೆಲ್ ಪಾರ್ಸರ್ ಅನ್ನು ಬಳಸಿದ್ದೇನೆ. ಎರಡೂ ಮೌಲ್ಯಗಳು 4 ವರ್ಷಗಳಿಂದ ಭಿನ್ನವಾಗಿದ್ದರೆ, ನಾನು ಯುಗ -1904 ನೊಂದಿಗೆ ಸಿಸ್ಟಮ್ ಅನ್ನು ಬಳಸುತ್ತಿದ್ದೇನೆ ಎಂದು ನನಗೆ ತಿಳಿದಿತ್ತು.

ನಾನು ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡಿದ ದಿನಾಂಕಗಳನ್ನು ಏಕೆ ಬಳಸಲಿಲ್ಲ? ಏಕೆಂದರೆ ಜುಲೈ 5, 1998 ಅನ್ನು ಕಳೆದುಹೋದ ತಿಂಗಳ ದಿನದೊಂದಿಗೆ "ಜುಲೈ, 98" ಎಂದು ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡಬಹುದು. ನಾವು ಹಲವಾರು ಕಂಪನಿಗಳಿಂದ ಕೋಷ್ಟಕಗಳನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇವೆ, ಅವುಗಳು ಹಲವಾರು ವಿಭಿನ್ನ ರೀತಿಯಲ್ಲಿ ಅವುಗಳನ್ನು ರಚಿಸಿದವು, ದಿನಾಂಕಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುವುದು ನಮಗೆ (ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನನಗೆ) ಬಿಟ್ಟದ್ದು. ಅದಲ್ಲದೆ, ಎಕ್ಸೆಲ್ ಅದನ್ನು ಸರಿಯಾಗಿ ಪಡೆದರೆ, ನಾವೂ ಹಾಗೆ ಮಾಡಬೇಕು!

ಅದೇ ಸಮಯದಲ್ಲಿ ನಾನು 39082 ಅನ್ನು ಎದುರಿಸಿದೆ. ಲೋಟಸ್ 1-2-3 1900 ಅನ್ನು ಅಧಿಕ ವರ್ಷವೆಂದು ಪರಿಗಣಿಸಿದೆ ಎಂದು ನಾನು ನಿಮಗೆ ನೆನಪಿಸುತ್ತೇನೆ ಮತ್ತು ಇದನ್ನು ಎಕ್ಸೆಲ್‌ನಲ್ಲಿ ನಿಷ್ಠೆಯಿಂದ ಪುನರಾವರ್ತಿಸಲಾಗಿದೆ. ಮತ್ತು ಇದು 1900 ನೇ ವರ್ಷಕ್ಕೆ ಒಂದು ದಿನವನ್ನು ಸೇರಿಸಿದಾಗಿನಿಂದ, ಆ ದಿನಕ್ಕೆ ಅನೇಕ ದಿನಾಂಕ ಲೆಕ್ಕಾಚಾರ ಕಾರ್ಯಗಳು ತಪ್ಪಾಗಿರಬಹುದು. ಅಂದರೆ, 39082 ಜನವರಿ 1, 2011 (ಮ್ಯಾಕ್‌ಗಳಲ್ಲಿ) ಅಥವಾ ಡಿಸೆಂಬರ್ 31, 2006 (ವಿಂಡೋಸ್‌ನಲ್ಲಿ) ಆಗಿರಬಹುದು. ನನ್ನ "ವರ್ಷದ ಪಾರ್ಸರ್" 2011 ವರ್ಷವನ್ನು ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡಿದ ಮೌಲ್ಯದಿಂದ ಹೊರತೆಗೆದರೆ, ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ. ಆದರೆ ಎಕ್ಸೆಲ್ ಪಾರ್ಸರ್‌ಗೆ ಯಾವ ಯುಗವನ್ನು ಬಳಸಲಾಗುತ್ತಿದೆ ಎಂದು ತಿಳಿದಿಲ್ಲವಾದ್ದರಿಂದ, ಇದು ಯುಗ-1900 ಗೆ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ 2006 ವರ್ಷವನ್ನು ಹಿಂದಿರುಗಿಸುತ್ತದೆ. ನನ್ನ ಅಪ್ಲಿಕೇಶನ್ 5 ವರ್ಷಗಳ ವ್ಯತ್ಯಾಸವನ್ನು ನೋಡಿದೆ, ಅದನ್ನು ದೋಷವೆಂದು ಪರಿಗಣಿಸಿದೆ, ಅದನ್ನು ಲಾಗ್ ಮಾಡಿದೆ ಮತ್ತು ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡದ ಮೌಲ್ಯವನ್ನು ಹಿಂತಿರುಗಿಸಿದೆ.

ಇದನ್ನು ಪಡೆಯಲು, ನಾನು ಇದನ್ನು ಬರೆದಿದ್ದೇನೆ (ಸೂಡೊಕೋಡ್):

diff = formatted_year - parsed_year
if 0 == diff
    assume 1900 date system
if 4 == diff
    assume 1904 date system
if 5 == diff and month is December and day is 31
    assume 1904 date system

ತದನಂತರ ಎಲ್ಲಾ 40 ದಿನಾಂಕಗಳನ್ನು ಸರಿಯಾಗಿ ಪಾರ್ಸ್ ಮಾಡಲಾಗಿದೆ.

ದೊಡ್ಡ ಮುದ್ರಣ ಉದ್ಯೋಗಗಳ ಮಧ್ಯದಲ್ಲಿ

1980 ರ ದಶಕದ ಆರಂಭದಲ್ಲಿ, ನನ್ನ ತಂದೆ ಸ್ಟೋರೇಜ್ ಟೆಕ್ನಾಲಜಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಿದರು, ಇದು ಈಗ ಕಾರ್ಯನಿರ್ವಹಿಸದ ವಿಭಾಗವಾಗಿದೆ, ಇದು ಹೈ-ಸ್ಪೀಡ್ ಟೇಪ್ ಫೀಡಿಂಗ್‌ಗಾಗಿ ಟೇಪ್ ಡ್ರೈವ್‌ಗಳು ಮತ್ತು ನ್ಯೂಮ್ಯಾಟಿಕ್ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ರಚಿಸಿತು.

ಅವರು ಡ್ರೈವ್‌ಗಳನ್ನು ಮರುವಿನ್ಯಾಸಗೊಳಿಸಿದರು ಇದರಿಂದ ಅವರು ಒಂದು ಕೇಂದ್ರೀಯ "A" ಡ್ರೈವ್ ಅನ್ನು ಏಳು "B" ಡ್ರೈವ್‌ಗಳಿಗೆ ಸಂಪರ್ಕಿಸಬಹುದು ಮತ್ತು "A" ಡ್ರೈವ್ ಅನ್ನು ನಿಯಂತ್ರಿಸುವ RAM ನಲ್ಲಿನ ಸಣ್ಣ OS ಎಲ್ಲಾ "B" ಡ್ರೈವ್‌ಗಳಿಗೆ ಓದುವ ಮತ್ತು ಬರೆಯುವ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಿಯೋಜಿಸಬಹುದು.

ಪ್ರತಿ ಬಾರಿ "A" ಡ್ರೈವ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಅದರ ಮೆಮೊರಿಗೆ ಲೋಡ್ ಮಾಡಲು "A" ಗೆ ಸಂಪರ್ಕಗೊಂಡಿರುವ ಬಾಹ್ಯ ಡ್ರೈವ್‌ಗೆ ಫ್ಲಾಪಿ ಡಿಸ್ಕ್ ಅನ್ನು ಸೇರಿಸುವುದು ಅವಶ್ಯಕ. ಇದು ಅತ್ಯಂತ ಪ್ರಾಚೀನವಾಗಿತ್ತು: 8-ಬಿಟ್ ಮೈಕ್ರೋಕಂಟ್ರೋಲರ್ ಮೂಲಕ ಕಂಪ್ಯೂಟಿಂಗ್ ಶಕ್ತಿಯನ್ನು ಒದಗಿಸಲಾಗಿದೆ.

ಅಂತಹ ಸಲಕರಣೆಗಳ ಗುರಿ ಪ್ರೇಕ್ಷಕರು ಬಹಳ ದೊಡ್ಡ ಡೇಟಾ ಗೋದಾಮುಗಳನ್ನು ಹೊಂದಿರುವ ಕಂಪನಿಗಳು - ಬ್ಯಾಂಕುಗಳು, ಚಿಲ್ಲರೆ ಸರಪಳಿಗಳು, ಇತ್ಯಾದಿ - ಇದು ಬಹಳಷ್ಟು ವಿಳಾಸ ಲೇಬಲ್‌ಗಳು ಅಥವಾ ಬ್ಯಾಂಕ್ ಹೇಳಿಕೆಗಳನ್ನು ಮುದ್ರಿಸಲು ಅಗತ್ಯವಿದೆ.

ಒಬ್ಬ ಗ್ರಾಹಕನಿಗೆ ಸಮಸ್ಯೆ ಇತ್ತು. ಮುದ್ರಣ ಕೆಲಸದ ಮಧ್ಯದಲ್ಲಿ, ಒಂದು ನಿರ್ದಿಷ್ಟ ಡ್ರೈವ್ "A" ಕೆಲಸ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಬಹುದು, ಇದರಿಂದಾಗಿ ಸಂಪೂರ್ಣ ಕೆಲಸ ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತದೆ. ಡ್ರೈವ್ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪುನಃಸ್ಥಾಪಿಸಲು, ಸಿಬ್ಬಂದಿ ಎಲ್ಲವನ್ನೂ ರೀಬೂಟ್ ಮಾಡಬೇಕಾಗಿತ್ತು. ಮತ್ತು ಇದು ಆರು ಗಂಟೆಗಳ ಕಾರ್ಯದ ಮಧ್ಯದಲ್ಲಿ ಸಂಭವಿಸಿದಲ್ಲಿ, ನಂತರ ಬೃಹತ್ ಪ್ರಮಾಣದ ದುಬಾರಿ ಕಂಪ್ಯೂಟರ್ ಸಮಯವನ್ನು ಕಳೆದುಕೊಂಡಿತು ಮತ್ತು ಸಂಪೂರ್ಣ ಕಾರ್ಯಾಚರಣೆಯ ವೇಳಾಪಟ್ಟಿಯನ್ನು ಅಡ್ಡಿಪಡಿಸುತ್ತದೆ.

ಸ್ಟೋರೇಜ್ ಟೆಕ್ನಾಲಜೀಸ್‌ನಿಂದ ತಂತ್ರಜ್ಞರನ್ನು ಕಳುಹಿಸಲಾಗಿದೆ. ಆದರೆ ಅವರ ಅತ್ಯುತ್ತಮ ಪ್ರಯತ್ನಗಳ ಹೊರತಾಗಿಯೂ, ಪರೀಕ್ಷಾ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ದೋಷವನ್ನು ಪುನರುತ್ಪಾದಿಸಲು ಅವರಿಗೆ ಸಾಧ್ಯವಾಗಲಿಲ್ಲ: ಇದು ದೊಡ್ಡ ಮುದ್ರಣ ಉದ್ಯೋಗಗಳ ಮಧ್ಯದಲ್ಲಿ ಸಂಭವಿಸುವಂತೆ ತೋರುತ್ತಿದೆ. ಸಮಸ್ಯೆಯು ಹಾರ್ಡ್‌ವೇರ್ ಅಲ್ಲ, ಅವರು ಸಾಧ್ಯವಿರುವ ಎಲ್ಲವನ್ನೂ ಬದಲಾಯಿಸಿದರು: RAM, ಮೈಕ್ರೋಕಂಟ್ರೋಲರ್, ಫ್ಲಾಪಿ ಡ್ರೈವ್, ಟೇಪ್ ಡ್ರೈವ್‌ನ ಪ್ರತಿಯೊಂದು ಕಲ್ಪಿತ ಭಾಗ - ಸಮಸ್ಯೆ ಮುಂದುವರೆಯಿತು.

ನಂತರ ತಂತ್ರಜ್ಞರು ಕೇಂದ್ರ ಕಚೇರಿಗೆ ಕರೆ ಮಾಡಿ ಎಕ್ಸ್‌ಪರ್ಟ್‌ಗೆ ಕರೆ ಮಾಡಿದರು.

ಪರಿಣಿತರು ಕುರ್ಚಿ ಮತ್ತು ಒಂದು ಕಪ್ ಕಾಫಿಯನ್ನು ಹಿಡಿದುಕೊಂಡರು, ಕಂಪ್ಯೂಟರ್ ಕೋಣೆಯಲ್ಲಿ ಕುಳಿತುಕೊಂಡರು-ಆ ದಿನಗಳಲ್ಲಿ ಕಂಪ್ಯೂಟರ್ಗಳಿಗೆ ಮೀಸಲಾದ ಕೊಠಡಿಗಳು ಇದ್ದವು-ಮತ್ತು ಸಿಬ್ಬಂದಿ ದೊಡ್ಡ ಮುದ್ರಣ ಕೆಲಸವನ್ನು ಸರದಿಯಲ್ಲಿ ನಿಲ್ಲಿಸುವುದನ್ನು ವೀಕ್ಷಿಸಿದರು. ವೈಫಲ್ಯ ಸಂಭವಿಸುವವರೆಗೆ ತಜ್ಞರು ಕಾಯುತ್ತಿದ್ದರು - ಮತ್ತು ಅದು ಮಾಡಿದೆ. ಎಲ್ಲರೂ ತಜ್ಞರನ್ನು ನೋಡಿದರು, ಆದರೆ ಇದು ಏಕೆ ಸಂಭವಿಸಿತು ಎಂದು ಅವನಿಗೆ ತಿಳಿದಿರಲಿಲ್ಲ. ಆದ್ದರಿಂದ ಅವರು ಕೆಲಸವನ್ನು ಮತ್ತೆ ಸರದಿಯಲ್ಲಿ ಇರಿಸಲು ಆದೇಶಿಸಿದರು ಮತ್ತು ಎಲ್ಲಾ ಸಿಬ್ಬಂದಿ ಮತ್ತು ತಂತ್ರಜ್ಞರು ಕೆಲಸಕ್ಕೆ ಮರಳಿದರು.

ತಜ್ಞರು ಮತ್ತೆ ಕುರ್ಚಿಯಲ್ಲಿ ಕುಳಿತು ವೈಫಲ್ಯಕ್ಕಾಗಿ ಕಾಯಲು ಪ್ರಾರಂಭಿಸಿದರು. ಸುಮಾರು ಆರು ಗಂಟೆಗಳು ಕಳೆದವು ಮತ್ತು ವೈಫಲ್ಯ ಸಂಭವಿಸಿದೆ. ತಜ್ಞರಿಗೆ ಮತ್ತೆ ಯಾವುದೇ ಆಲೋಚನೆಗಳು ಇರಲಿಲ್ಲ, ಎಲ್ಲವೂ ಜನರಿಂದ ತುಂಬಿದ ಕೋಣೆಯಲ್ಲಿ ಸಂಭವಿಸಿದವು. ಅವರು ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪುನರಾರಂಭಿಸಲು ಆದೇಶಿಸಿದರು, ಮತ್ತೆ ಕುಳಿತು ಕಾಯುತ್ತಿದ್ದರು.

ಮೂರನೇ ವೈಫಲ್ಯದಿಂದ, ತಜ್ಞರು ಏನನ್ನಾದರೂ ಗಮನಿಸಿದರು. ಸಿಬ್ಬಂದಿ ವಿದೇಶಿ ಡ್ರೈವ್‌ನಲ್ಲಿ ಟೇಪ್‌ಗಳನ್ನು ಬದಲಾಯಿಸಿದಾಗ ವೈಫಲ್ಯ ಸಂಭವಿಸಿದೆ. ಇದಲ್ಲದೆ, ಉದ್ಯೋಗಿಯೊಬ್ಬರು ನೆಲದ ಮೇಲೆ ಒಂದು ನಿರ್ದಿಷ್ಟ ಟೈಲ್ ಮೂಲಕ ನಡೆದ ತಕ್ಷಣ ವೈಫಲ್ಯ ಸಂಭವಿಸಿದೆ.

ಎತ್ತರಿಸಿದ ನೆಲವನ್ನು 6 ರಿಂದ 8 ಇಂಚು ಎತ್ತರದಲ್ಲಿ ಅಲ್ಯೂಮಿನಿಯಂ ಟೈಲ್ಸ್‌ಗಳಿಂದ ಮಾಡಲಾಗಿತ್ತು. ಯಾರಾದರೂ ಆಕಸ್ಮಿಕವಾಗಿ ಒಂದು ಪ್ರಮುಖ ಕೇಬಲ್‌ಗೆ ಕಾಲಿಡುವುದನ್ನು ತಡೆಯಲು ಕಂಪ್ಯೂಟರ್‌ಗಳಿಂದ ಹಲವಾರು ತಂತಿಗಳು ಎತ್ತರದ ನೆಲದ ಅಡಿಯಲ್ಲಿ ಓಡಿದವು. ಎತ್ತರಿಸಿದ ನೆಲದ ಕೆಳಗೆ ಶಿಲಾಖಂಡರಾಶಿಗಳು ಬರದಂತೆ ತಡೆಯಲು ಟೈಲ್ಸ್ ಅನ್ನು ಬಹಳ ಬಿಗಿಯಾಗಿ ಹಾಕಲಾಗಿದೆ.

ಅಂಚುಗಳಲ್ಲಿ ಒಂದನ್ನು ವಿರೂಪಗೊಳಿಸಲಾಗಿದೆ ಎಂದು ತಜ್ಞರು ಅರಿತುಕೊಂಡರು. ಉದ್ಯೋಗಿ ಅದರ ಮೂಲೆಯಲ್ಲಿ ಹೆಜ್ಜೆ ಹಾಕಿದಾಗ, ಟೈಲ್ನ ಅಂಚುಗಳು ಪಕ್ಕದ ಅಂಚುಗಳಿಗೆ ಉಜ್ಜಿದವು. ಅಂಚುಗಳನ್ನು ಸಂಪರ್ಕಿಸುವ ಪ್ಲಾಸ್ಟಿಕ್ ಭಾಗಗಳು ಸಹ ಅವರೊಂದಿಗೆ ಉಜ್ಜಿದವು, ಇದು ರೇಡಿಯೊ ಆವರ್ತನ ಹಸ್ತಕ್ಷೇಪವನ್ನು ಸೃಷ್ಟಿಸುವ ಸ್ಥಿರ ಮೈಕ್ರೊಡಿಸ್ಚಾರ್ಜ್ಗಳಿಗೆ ಕಾರಣವಾಯಿತು.

ಇಂದು, ರೇಡಿಯೊ ಆವರ್ತನ ಹಸ್ತಕ್ಷೇಪದಿಂದ RAM ಅನ್ನು ಉತ್ತಮವಾಗಿ ರಕ್ಷಿಸಲಾಗಿದೆ. ಆದರೆ ಆ ವರ್ಷಗಳಲ್ಲಿ ಇದು ಹಾಗಿರಲಿಲ್ಲ. ಈ ಹಸ್ತಕ್ಷೇಪವು ಮೆಮೊರಿಯನ್ನು ಅಡ್ಡಿಪಡಿಸುತ್ತದೆ ಮತ್ತು ಅದರೊಂದಿಗೆ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂನ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ತಜ್ಞರು ಅರಿತುಕೊಂಡರು. ಅವರು ಬೆಂಬಲ ಸೇವೆಯನ್ನು ಕರೆದರು, ಹೊಸ ಅಂಚುಗಳನ್ನು ಆದೇಶಿಸಿದರು, ಅವುಗಳನ್ನು ಸ್ವತಃ ಸ್ಥಾಪಿಸಿದರು ಮತ್ತು ಸಮಸ್ಯೆ ಕಣ್ಮರೆಯಾಯಿತು.

ಇದು ಉಬ್ಬರವಿಳಿತ!

ಈ ಕಥೆಯು ಪೋರ್ಟ್ಸ್‌ಮೌತ್‌ನಲ್ಲಿರುವ (ನನ್ನ ಪ್ರಕಾರ) ಕಛೇರಿಯ ನಾಲ್ಕನೇ ಅಥವಾ ಐದನೇ ಮಹಡಿಯಲ್ಲಿ ಡಾಕ್ಸ್ ಪ್ರದೇಶದಲ್ಲಿ ಸರ್ವರ್ ಕೋಣೆಯಲ್ಲಿ ನಡೆಯಿತು.

ಒಂದು ದಿನ ಮುಖ್ಯ ಡೇಟಾಬೇಸ್ ಹೊಂದಿರುವ ಯುನಿಕ್ಸ್ ಸರ್ವರ್ ಕ್ರ್ಯಾಶ್ ಆಗಿತ್ತು. ಅವರು ಅವನನ್ನು ರೀಬೂಟ್ ಮಾಡಿದರು, ಆದರೆ ಅವನು ಸಂತೋಷದಿಂದ ಮತ್ತೆ ಮತ್ತೆ ಬೀಳುವುದನ್ನು ಮುಂದುವರೆಸಿದನು. ನಾವು ಬೆಂಬಲ ಸೇವೆಯಿಂದ ಯಾರನ್ನಾದರೂ ಕರೆ ಮಾಡಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.

ಬೆಂಬಲಿಗ ವ್ಯಕ್ತಿ... ಅವನ ಹೆಸರು ಮಾರ್ಕ್ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ, ಆದರೆ ಅದು ಅಪ್ರಸ್ತುತವಾಗುತ್ತದೆ ... ನಾನು ಅವನನ್ನು ತಿಳಿದಿದ್ದೇನೆ ಎಂದು ನಾನು ಭಾವಿಸುವುದಿಲ್ಲ. ಇದು ಪರವಾಗಿಲ್ಲ, ನಿಜವಾಗಿಯೂ. ಮಾರ್ಕ್ ಜೊತೆ ಅಂಟಿಕೊಳ್ಳೋಣ, ಸರಿ? ಕುವೆಂಪು.

ಆದ್ದರಿಂದ, ಕೆಲವು ಗಂಟೆಗಳ ನಂತರ ಮಾರ್ಕ್ ಬಂದರು (ಇದು ಲೀಡ್ಸ್‌ನಿಂದ ಪೋರ್ಟ್ಸ್‌ಮೌತ್‌ಗೆ ಬಹಳ ದೂರವಿಲ್ಲ, ನಿಮಗೆ ತಿಳಿದಿದೆ), ಸರ್ವರ್ ಅನ್ನು ಆನ್ ಮಾಡಿದೆ ಮತ್ತು ಎಲ್ಲವೂ ಸಮಸ್ಯೆಗಳಿಲ್ಲದೆ ಕೆಲಸ ಮಾಡಿತು. ವಿಶಿಷ್ಟವಾದ ಡ್ಯಾಮ್ ಬೆಂಬಲ, ಕ್ಲೈಂಟ್ ಈ ಬಗ್ಗೆ ತುಂಬಾ ಅಸಮಾಧಾನಗೊಳ್ಳುತ್ತಾನೆ. ಮಾರ್ಕ್ ಲಾಗ್ ಫೈಲ್‌ಗಳ ಮೂಲಕ ನೋಡುತ್ತಾನೆ ಮತ್ತು ಅಹಿತಕರವಾದದ್ದನ್ನು ಕಂಡುಕೊಳ್ಳುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ ಮಾರ್ಕ್ ರೈಲಿನಲ್ಲಿ ಹಿಂತಿರುಗುತ್ತಾನೆ (ಅಥವಾ ಅವನು ಬಂದ ಯಾವುದೇ ಸಾರಿಗೆ ವಿಧಾನ, ಅದು ನನಗೆ ತಿಳಿದಿರುವ ಎಲ್ಲಾ ಕುಂಟ ಹಸುವಾಗಿರಬಹುದು ... ಹೇಗಾದರೂ ಪರವಾಗಿಲ್ಲ, ಸರಿ?) ಮತ್ತು ವ್ಯರ್ಥವಾಗಿ ಲೀಡ್ಸ್‌ಗೆ ಹಿಂತಿರುಗುತ್ತಾನೆ ದಿನ.

ಅದೇ ಸಂಜೆ ಮತ್ತೆ ಸರ್ವರ್ ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತದೆ. ಕಥೆಯೂ ಅದೇ... ಸರ್ವರಿಗೂ ಏಳುವುದಿಲ್ಲ. ಮಾರ್ಕ್ ರಿಮೋಟ್ ಆಗಿ ಸಹಾಯ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತಾನೆ, ಆದರೆ ಕ್ಲೈಂಟ್ ಸರ್ವರ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಮತ್ತೊಂದು ರೈಲು, ಬಸ್, ನಿಂಬೆ ಮೆರಿಂಗ್ಯೂ ಅಥವಾ ಇತರ ಕೆಲವು ಅಮೇಧ್ಯ, ಮತ್ತು ಮಾರ್ಕ್ ಪೋರ್ಟ್ಸ್ಮೌತ್‌ಗೆ ಹಿಂತಿರುಗಿದ್ದಾರೆ. ನೋಡಿ, ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿಲ್ಲದೆ ಸರ್ವರ್ ಬೂಟ್ ಆಗುತ್ತದೆ! ಪವಾಡ. ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಅಥವಾ ಸಾಫ್ಟ್‌ವೇರ್‌ನೊಂದಿಗೆ ಎಲ್ಲವೂ ಕ್ರಮದಲ್ಲಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಲು ಮಾರ್ಕ್ ಹಲವಾರು ಗಂಟೆಗಳ ಕಾಲ ಕಳೆಯುತ್ತಾನೆ ಮತ್ತು ಲೀಡ್ಸ್‌ಗೆ ಹೊರಡುತ್ತಾನೆ.

ದಿನದ ಮಧ್ಯದಲ್ಲಿ ಸರ್ವರ್ ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತದೆ (ಸುಲಭವಾಗಿ ತೆಗೆದುಕೊಳ್ಳಿ!). ಈ ಬಾರಿ ಸರ್ವರ್ ಅನ್ನು ಬದಲಿಸಲು ಹಾರ್ಡ್‌ವೇರ್ ಬೆಂಬಲ ಜನರನ್ನು ತರಲು ಸಮಂಜಸವಾಗಿದೆ. ಆದರೆ ಇಲ್ಲ, ಸುಮಾರು 10 ಗಂಟೆಗಳ ನಂತರ ಅದು ಬೀಳುತ್ತದೆ.

ಹಲವಾರು ದಿನಗಳವರೆಗೆ ಪರಿಸ್ಥಿತಿ ಪುನರಾವರ್ತನೆಯಾಯಿತು. ಸರ್ವರ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಸುಮಾರು 10 ಗಂಟೆಗಳ ನಂತರ ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ 2 ಗಂಟೆಗಳವರೆಗೆ ಪ್ರಾರಂಭವಾಗುವುದಿಲ್ಲ. ಅವರು ಕೂಲಿಂಗ್, ಮೆಮೊರಿ ಸೋರಿಕೆಯನ್ನು ಪರಿಶೀಲಿಸಿದರು, ಅವರು ಎಲ್ಲವನ್ನೂ ಪರಿಶೀಲಿಸಿದರು, ಆದರೆ ಏನೂ ಕಂಡುಬಂದಿಲ್ಲ. ನಂತರ ಕುಸಿತಗಳು ನಿಂತುಹೋದವು.

ವಾರ ನಿರಾತಂಕವಾಗಿ ಕಳೆಯಿತು... ಎಲ್ಲರೂ ಖುಷಿಯಾದರು. ಎಲ್ಲವೂ ಮತ್ತೆ ಪ್ರಾರಂಭವಾಗುವವರೆಗೆ ಸಂತೋಷವಾಗಿದೆ. ಚಿತ್ರವೂ ಅದೇ ಆಗಿದೆ. 10 ಗಂಟೆಗಳ ಕೆಲಸ, 2-3 ಗಂಟೆಗಳ ಅಲಭ್ಯತೆ...

ತದನಂತರ ಯಾರೋ (ಈ ವ್ಯಕ್ತಿಗೆ ಐಟಿಯೊಂದಿಗೆ ಯಾವುದೇ ಸಂಬಂಧವಿಲ್ಲ ಎಂದು ಅವರು ನನಗೆ ಹೇಳಿದರು ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ) ಹೇಳಿದರು:

"ಇದು ಉಬ್ಬರವಿಳಿತ!"

ಆಶ್ಚರ್ಯವನ್ನು ಖಾಲಿ ದಿಟ್ಟಿಸುವಿಕೆಯೊಂದಿಗೆ ಎದುರಿಸಲಾಯಿತು, ಮತ್ತು ಯಾರೋ ಒಬ್ಬರು ಬಹುಶಃ ಭದ್ರತಾ ಕರೆ ಬಟನ್‌ನಲ್ಲಿ ಹಿಂಜರಿಯುತ್ತಾರೆ.

"ಇದು ಉಬ್ಬರವಿಳಿತದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ."

ಐಟಿ ಬೆಂಬಲ ಕೆಲಸಗಾರರಿಗೆ ಇದು ಸಂಪೂರ್ಣವಾಗಿ ವಿದೇಶಿ ಪರಿಕಲ್ಪನೆಯಂತೆ ತೋರುತ್ತದೆ, ಅವರು ಕಾಫಿಗಾಗಿ ಕುಳಿತುಕೊಳ್ಳುವಾಗ ಟೈಡ್ ಇಯರ್‌ಬುಕ್ ಅನ್ನು ಓದಲು ಅಸಂಭವವಾಗಿದೆ. ಇದು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಉಬ್ಬರವಿಳಿತಕ್ಕೆ ಸಂಬಂಧಿಸುವುದಿಲ್ಲ ಎಂದು ಅವರು ವಿವರಿಸಿದರು, ಏಕೆಂದರೆ ಸರ್ವರ್ ವೈಫಲ್ಯಗಳಿಲ್ಲದೆ ಒಂದು ವಾರದಿಂದ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ.

"ಕಳೆದ ವಾರ ಉಬ್ಬರವಿಳಿತವು ಕಡಿಮೆಯಾಗಿತ್ತು, ಆದರೆ ಈ ವಾರ ಅದು ಹೆಚ್ಚಾಗಿದೆ."

ವಿಹಾರ ಪರವಾನಗಿ ಇಲ್ಲದವರಿಗೆ ಸ್ವಲ್ಪ ಪರಿಭಾಷೆ. ಉಬ್ಬರವಿಳಿತಗಳು ಚಂದ್ರನ ಚಕ್ರವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ. ಮತ್ತು ಭೂಮಿಯು ತಿರುಗುತ್ತಿರುವಾಗ, ಪ್ರತಿ 12,5 ಗಂಟೆಗಳಿಗೊಮ್ಮೆ ಸೂರ್ಯ ಮತ್ತು ಚಂದ್ರನ ಗುರುತ್ವಾಕರ್ಷಣೆಯು ಉಬ್ಬರವಿಳಿತದ ಅಲೆಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. 12,5-ಗಂಟೆಗಳ ಚಕ್ರದ ಆರಂಭದಲ್ಲಿ ಹೆಚ್ಚಿನ ಉಬ್ಬರವಿಳಿತವಿದೆ, ಚಕ್ರದ ಮಧ್ಯದಲ್ಲಿ ಉಬ್ಬರವಿಳಿತವಿದೆ ಮತ್ತು ಕೊನೆಯಲ್ಲಿ ಮತ್ತೆ ಉಬ್ಬರವಿಳಿತವಿದೆ. ಆದರೆ ಚಂದ್ರನ ಕಕ್ಷೆಯು ಬದಲಾದಂತೆ, ಕಡಿಮೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಉಬ್ಬರವಿಳಿತದ ನಡುವಿನ ವ್ಯತ್ಯಾಸವು ಬದಲಾಗುತ್ತದೆ. ಚಂದ್ರನು ಸೂರ್ಯ ಮತ್ತು ಭೂಮಿಯ ನಡುವೆ ಅಥವಾ ಭೂಮಿಯ ಎದುರು ಭಾಗದಲ್ಲಿದ್ದಾಗ (ಹುಣ್ಣಿಮೆ ಅಥವಾ ಚಂದ್ರನಿಲ್ಲ), ನಾವು Syzygyn ಉಬ್ಬರವಿಳಿತಗಳನ್ನು ಪಡೆಯುತ್ತೇವೆ - ಅತ್ಯುನ್ನತ ಉಬ್ಬರವಿಳಿತಗಳು ಮತ್ತು ಕಡಿಮೆ ಉಬ್ಬರವಿಳಿತಗಳು. ಅರ್ಧ ಚಂದ್ರನಲ್ಲಿ ನಾವು ಚತುರ್ಭುಜ ಉಬ್ಬರವಿಳಿತಗಳನ್ನು ಪಡೆಯುತ್ತೇವೆ - ಕಡಿಮೆ ಉಬ್ಬರವಿಳಿತಗಳು. ಎರಡು ವಿಪರೀತಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸವು ಬಹಳವಾಗಿ ಕಡಿಮೆಯಾಗುತ್ತದೆ. ಚಂದ್ರನ ಚಕ್ರವು 28 ದಿನಗಳವರೆಗೆ ಇರುತ್ತದೆ: ಸಿಜಿಜಿಯನ್ - ಕ್ವಾಡ್ರೇಚರ್ - ಸಿಜಿಜಿಯನ್ - ಕ್ವಾಡ್ರೇಚರ್.

ಉಬ್ಬರವಿಳಿತದ ಶಕ್ತಿಗಳ ಸಾರವನ್ನು ತಂತ್ರಜ್ಞರಿಗೆ ವಿವರಿಸಿದಾಗ, ಅವರು ತಕ್ಷಣವೇ ಪೊಲೀಸರನ್ನು ಕರೆಯಬೇಕಾಗಿದೆ ಎಂದು ಭಾವಿಸಿದರು. ಮತ್ತು ಸಾಕಷ್ಟು ತಾರ್ಕಿಕ. ಆದರೆ ಸೊಗಸುಗಾರ ಹೇಳಿದ್ದು ಸರಿ ಎಂದು ತಿರುಗುತ್ತದೆ. ಎರಡು ವಾರಗಳ ಹಿಂದೆ, ಒಂದು ವಿಧ್ವಂಸಕ ಕಛೇರಿಯಿಂದ ಸ್ವಲ್ಪ ದೂರದಲ್ಲಿ ನಿಂತಿತು. ಪ್ರತಿ ಬಾರಿ ಉಬ್ಬರವಿಳಿತವು ಅದನ್ನು ನಿರ್ದಿಷ್ಟ ಎತ್ತರಕ್ಕೆ ಏರಿಸಿದಾಗ, ಹಡಗಿನ ರಾಡಾರ್ ಪೋಸ್ಟ್ ಸರ್ವರ್ ರೂಮ್ ನೆಲದ ಮಟ್ಟದಲ್ಲಿ ಕೊನೆಗೊಂಡಿತು. ಮತ್ತು ರಾಡಾರ್ (ಅಥವಾ ಎಲೆಕ್ಟ್ರಾನಿಕ್ ಯುದ್ಧ ಉಪಕರಣಗಳು, ಅಥವಾ ಕೆಲವು ಇತರ ಮಿಲಿಟರಿ ಆಟಿಕೆ) ಕಂಪ್ಯೂಟರ್‌ಗಳಲ್ಲಿ ಅವ್ಯವಸ್ಥೆಯನ್ನು ಸೃಷ್ಟಿಸಿತು.

ರಾಕೆಟ್‌ಗಾಗಿ ಫ್ಲೈಟ್ ಮಿಷನ್

ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂ, ಕಂಪೈಲರ್ ಮತ್ತು ಭಾಷೆಯ ಹೊಸ ಆವೃತ್ತಿಗಳಿಗೆ ದೊಡ್ಡ (ಸುಮಾರು 400 ಸಾವಿರ ಸಾಲುಗಳು) ರಾಕೆಟ್ ಉಡಾವಣಾ ನಿಯಂತ್ರಣ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಯನ್ನು ಪೋರ್ಟ್ ಮಾಡಲು ನನಗೆ ವಹಿಸಲಾಯಿತು. ಹೆಚ್ಚು ನಿಖರವಾಗಿ ಹೇಳುವುದಾದರೆ, ಸೋಲಾರಿಸ್ 2.5.1 ರಿಂದ ಸೋಲಾರಿಸ್ 7 ವರೆಗೆ ಮತ್ತು ಅದಾ 83 ರಲ್ಲಿ ಬರೆಯಲಾದ ವರ್ಡಿಕ್ಸ್ ಅಡಾ ಡೆವಲಪ್‌ಮೆಂಟ್ ಸಿಸ್ಟಮ್ (VADS) ನಿಂದ ಅಡಾ 95 ರಲ್ಲಿ ಬರೆಯಲಾದ ತರ್ಕಬದ್ಧ ಅಪೆಕ್ಸ್ ಅಡಾ ಸಿಸ್ಟಮ್‌ಗೆ. VADS ಅನ್ನು Rational ನಿಂದ ಖರೀದಿಸಲಾಯಿತು ಮತ್ತು ಅದರ ಉತ್ಪನ್ನವಾಗಿತ್ತು ಅಪೆಕ್ಸ್ ಕಂಪೈಲರ್‌ಗೆ ಸ್ಥಿತ್ಯಂತರವನ್ನು ಸುಲಭಗೊಳಿಸಲು VADS-ನಿರ್ದಿಷ್ಟ ಪ್ಯಾಕೇಜ್‌ಗಳ ಹೊಂದಾಣಿಕೆಯ ಆವೃತ್ತಿಗಳನ್ನು ಅಳವಡಿಸಲು ತರ್ಕಬದ್ಧ ಪ್ರಯತ್ನಿಸಿದರೂ ಬಳಕೆಯಲ್ಲಿಲ್ಲ.

ಕೋಡ್ ಅನ್ನು ಸ್ವಚ್ಛವಾಗಿ ಕಂಪೈಲ್ ಮಾಡಲು ಮೂರು ಜನರು ನನಗೆ ಸಹಾಯ ಮಾಡಿದರು. ಇದು ಎರಡು ವಾರಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು. ತದನಂತರ ನಾನು ಸಿಸ್ಟಮ್ ಕೆಲಸ ಮಾಡಲು ನನ್ನ ಸ್ವಂತ ಕೆಲಸ ಮಾಡಿದೆ. ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳುವುದಾದರೆ, ಇದು ನಾನು ಎದುರಿಸಿದ ಸಾಫ್ಟ್‌ವೇರ್ ಸಿಸ್ಟಮ್‌ನ ಕೆಟ್ಟ ವಾಸ್ತುಶಿಲ್ಪ ಮತ್ತು ಅನುಷ್ಠಾನವಾಗಿದೆ, ಆದ್ದರಿಂದ ಬಂದರನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಇನ್ನೂ ಎರಡು ತಿಂಗಳುಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು. ನಂತರ ವ್ಯವಸ್ಥೆಯನ್ನು ಪರೀಕ್ಷೆಗೆ ಸಲ್ಲಿಸಲಾಯಿತು, ಇದು ಹಲವಾರು ತಿಂಗಳುಗಳನ್ನು ತೆಗೆದುಕೊಂಡಿತು. ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ ಕಂಡುಬಂದ ದೋಷಗಳನ್ನು ನಾನು ತಕ್ಷಣ ಸರಿಪಡಿಸಿದೆ, ಆದರೆ ಅವುಗಳ ಸಂಖ್ಯೆ ತ್ವರಿತವಾಗಿ ಕಡಿಮೆಯಾಯಿತು (ಮೂಲ ಕೋಡ್ ಉತ್ಪಾದನಾ ವ್ಯವಸ್ಥೆಯಾಗಿದೆ, ಆದ್ದರಿಂದ ಅದರ ಕಾರ್ಯವು ಸಾಕಷ್ಟು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಕೆಲಸ ಮಾಡಿದೆ, ಹೊಸ ಕಂಪೈಲರ್‌ಗೆ ಹೊಂದಿಕೊಳ್ಳುವ ಸಮಯದಲ್ಲಿ ಉದ್ಭವಿಸಿದ ದೋಷಗಳನ್ನು ನಾನು ತೆಗೆದುಹಾಕಬೇಕಾಗಿತ್ತು). ಅಂತಿಮವಾಗಿ, ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡುವಾಗ, ನಾನು ಇನ್ನೊಂದು ಯೋಜನೆಗೆ ವರ್ಗಾಯಿಸಲ್ಪಟ್ಟೆ.

ಮತ್ತು ಥ್ಯಾಂಕ್ಸ್ಗಿವಿಂಗ್ ಹಿಂದಿನ ಶುಕ್ರವಾರ, ಫೋನ್ ರಿಂಗಾಯಿತು.

ರಾಕೆಟ್ ಉಡಾವಣೆಯನ್ನು ಸುಮಾರು ಮೂರು ವಾರಗಳಲ್ಲಿ ಪರೀಕ್ಷಿಸಬೇಕಾಗಿತ್ತು ಮತ್ತು ಕೌಂಟ್‌ಡೌನ್‌ನ ಪ್ರಯೋಗಾಲಯ ಪರೀಕ್ಷೆಗಳ ಸಮಯದಲ್ಲಿ, ಆಜ್ಞೆಗಳ ಅನುಕ್ರಮವನ್ನು ನಿರ್ಬಂಧಿಸಲಾಗಿದೆ. ನಿಜ ಜೀವನದಲ್ಲಿ, ಇದು ಪರೀಕ್ಷೆಯನ್ನು ಸ್ಥಗಿತಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಎಂಜಿನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದ ಕೆಲವೇ ಸೆಕೆಂಡುಗಳಲ್ಲಿ ತಡೆಗಟ್ಟುವಿಕೆ ಸಂಭವಿಸಿದಲ್ಲಿ, ಸಹಾಯಕ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಹಲವಾರು ಬದಲಾಯಿಸಲಾಗದ ಕ್ರಿಯೆಗಳು ಸಂಭವಿಸುತ್ತವೆ, ಇದು ರಾಕೆಟ್ನ ದೀರ್ಘ ಮತ್ತು ದುಬಾರಿ ಸಿದ್ಧತೆಯ ಅಗತ್ಯವಿರುತ್ತದೆ. ಇದು ಪ್ರಾರಂಭವಾಗುತ್ತಿರಲಿಲ್ಲ, ಆದರೆ ಬಹಳಷ್ಟು ಜನರು ಸಮಯ ಮತ್ತು ಬಹಳಷ್ಟು ಹಣದ ನಷ್ಟದ ಬಗ್ಗೆ ತುಂಬಾ ಅಸಮಾಧಾನಗೊಂಡಿದ್ದಾರೆ. ಡಿಪಾರ್ಟ್ಮೆಂಟ್ ಆಫ್ ಡಿಫೆನ್ಸ್ ಅಜಾಗರೂಕತೆಯಿಂದ ಹಣವನ್ನು ಖರ್ಚು ಮಾಡುತ್ತದೆ ಎಂದು ಯಾರಿಗೂ ಹೇಳಲು ಬಿಡಬೇಡಿ - ನಾನು ಬಜೆಟ್ ಅನ್ನು ಮೊದಲ ಅಥವಾ ಎರಡನೆಯದನ್ನು ನಿಗದಿಪಡಿಸದ, ನಂತರ ವೇಳಾಪಟ್ಟಿಯನ್ನು ಅನುಸರಿಸದ ಗುತ್ತಿಗೆ ವ್ಯವಸ್ಥಾಪಕರನ್ನು ನಾನು ಎಂದಿಗೂ ಭೇಟಿ ಮಾಡಿಲ್ಲ.

ಹಿಂದಿನ ತಿಂಗಳುಗಳಲ್ಲಿ, ಈ ಕೌಂಟ್‌ಡೌನ್ ಸವಾಲನ್ನು ನೂರಾರು ಬಾರಿ ಹಲವಾರು ಮಾರ್ಪಾಡುಗಳಲ್ಲಿ ನಡೆಸಲಾಯಿತು, ಕೆಲವೇ ಸಣ್ಣ ಬಿಕ್ಕಳಿಕೆಗಳೊಂದಿಗೆ. ಆದ್ದರಿಂದ ಇದು ಸಂಭವಿಸುವ ಸಾಧ್ಯತೆಯು ತುಂಬಾ ಕಡಿಮೆಯಾಗಿದೆ, ಆದರೆ ಅದರ ಪರಿಣಾಮಗಳು ಬಹಳ ಮಹತ್ವದ್ದಾಗಿದ್ದವು. ಈ ಎರಡೂ ಅಂಶಗಳನ್ನು ಗುಣಿಸಿ, ಮತ್ತು ನನಗೆ ಮತ್ತು ಡಜನ್‌ಗಟ್ಟಲೆ ಎಂಜಿನಿಯರ್‌ಗಳು ಮತ್ತು ಮ್ಯಾನೇಜರ್‌ಗಳಿಗೆ ವಾರದ ನಾಶವಾದ ರಜಾದಿನವನ್ನು ಸುದ್ದಿ ಭವಿಷ್ಯ ನುಡಿದಿದೆ ಎಂದು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವಿರಿ.

ಮತ್ತು ಸಿಸ್ಟಮ್ ಅನ್ನು ಪೋರ್ಟ್ ಮಾಡಿದ ವ್ಯಕ್ತಿಯಾಗಿ ನನಗೆ ಗಮನ ನೀಡಲಾಯಿತು.

ಹೆಚ್ಚಿನ ಭದ್ರತಾ-ನಿರ್ಣಾಯಕ ವ್ಯವಸ್ಥೆಗಳಂತೆ, ಬಹಳಷ್ಟು ನಿಯತಾಂಕಗಳನ್ನು ಲಾಗ್ ಮಾಡಲಾಗಿದೆ, ಆದ್ದರಿಂದ ಸಿಸ್ಟಮ್ ಕ್ರ್ಯಾಶ್ ಆಗುವ ಮೊದಲು ಕಾರ್ಯಗತಗೊಳಿಸಿದ ಕೋಡ್‌ನ ಕೆಲವು ಸಾಲುಗಳನ್ನು ಗುರುತಿಸುವುದು ಸಾಕಷ್ಟು ಸುಲಭವಾಗಿದೆ. ಮತ್ತು ಸಹಜವಾಗಿ, ಅವರಲ್ಲಿ ಅಸಾಮಾನ್ಯವಾದ ಏನೂ ಇರಲಿಲ್ಲ; ಅದೇ ಅಭಿವ್ಯಕ್ತಿಗಳು ಒಂದೇ ಓಟದಲ್ಲಿ ಅಕ್ಷರಶಃ ಸಾವಿರಾರು ಬಾರಿ ಯಶಸ್ವಿಯಾಗಿ ಕಾರ್ಯಗತಗೊಂಡಿವೆ.

ನಾವು ಅಪೆಕ್ಸ್‌ನಿಂದ ಜನರನ್ನು ತರ್ಕಬದ್ಧವಾಗಿ ಕರೆದಿದ್ದೇವೆ ಏಕೆಂದರೆ ಅವರು ಕಂಪೈಲರ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದಾರೆ ಮತ್ತು ಅವರು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ ಕೆಲವು ದಿನಚರಿಗಳನ್ನು ಅನುಮಾನಾಸ್ಪದ ಕೋಡ್‌ನಲ್ಲಿ ಕರೆಯಲಾಗಿದೆ. ಅಕ್ಷರಶಃ ರಾಷ್ಟ್ರೀಯ ಪ್ರಾಮುಖ್ಯತೆಯ ಸಮಸ್ಯೆಯ ಮೂಲವನ್ನು ಪಡೆಯುವ ಅವಶ್ಯಕತೆಯಿದೆ ಎಂದು ಅವರು (ಮತ್ತು ಎಲ್ಲರೂ) ಪ್ರಭಾವಿತರಾದರು.

ನಿಯತಕಾಲಿಕಗಳಲ್ಲಿ ಆಸಕ್ತಿದಾಯಕ ಏನೂ ಇಲ್ಲದಿರುವುದರಿಂದ, ಸ್ಥಳೀಯ ಪ್ರಯೋಗಾಲಯದಲ್ಲಿ ಸಮಸ್ಯೆಯನ್ನು ಪುನರುತ್ಪಾದಿಸಲು ಪ್ರಯತ್ನಿಸಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. 1000 ರನ್‌ಗಳಿಗೆ ಸರಿಸುಮಾರು ಒಮ್ಮೆ ಈವೆಂಟ್ ಸಂಭವಿಸಿದ ಕಾರಣ ಇದು ಸುಲಭದ ಕೆಲಸವಾಗಿರಲಿಲ್ಲ. ಒಂದು ಶಂಕಿತ ಕಾರಣವೆಂದರೆ ಮಾರಾಟಗಾರ-ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ ಮ್ಯೂಟೆಕ್ಸ್ ಕಾರ್ಯಕ್ಕೆ ಕರೆ (VADS ವಲಸೆ ಪ್ಯಾಕೇಜ್‌ನ ಭಾಗ) Unlock ಅನ್ಲಾಕ್ ಮಾಡಲು ಕಾರಣವಾಗಲಿಲ್ಲ. ಕಾರ್ಯವನ್ನು ಕರೆಯುವ ಸಂಸ್ಕರಣಾ ಥ್ರೆಡ್ ಹೃದಯ ಬಡಿತದ ಸಂದೇಶಗಳನ್ನು ಸಂಸ್ಕರಿಸುತ್ತದೆ, ಇದು ನಾಮಮಾತ್ರವಾಗಿ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಆಗಮಿಸುತ್ತದೆ. ನಾವು ಆವರ್ತನವನ್ನು 10 Hz ಗೆ ಹೆಚ್ಚಿಸಿದ್ದೇವೆ, ಅಂದರೆ, ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 10 ಬಾರಿ, ಮತ್ತು ಚಾಲನೆಯಲ್ಲಿದೆ. ಸುಮಾರು ಒಂದು ಗಂಟೆಯ ನಂತರ ಸಿಸ್ಟಮ್ ಸ್ವತಃ ಲಾಕ್ ಆಗಿದೆ. ಲಾಗ್‌ನಲ್ಲಿ, ರೆಕಾರ್ಡ್ ಮಾಡಿದ ಸಂದೇಶಗಳ ಅನುಕ್ರಮವು ವಿಫಲವಾದ ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ ಒಂದೇ ಆಗಿರುವುದನ್ನು ನಾವು ನೋಡಿದ್ದೇವೆ. ನಾವು ಇನ್ನೂ ಹಲವಾರು ರನ್‌ಗಳನ್ನು ಮಾಡಿದ್ದೇವೆ, ಪ್ರಾರಂಭದ ನಂತರ 45-90 ನಿಮಿಷಗಳ ನಂತರ ಸಿಸ್ಟಮ್ ಅನ್ನು ಸ್ಥಿರವಾಗಿ ನಿರ್ಬಂಧಿಸಲಾಗಿದೆ ಮತ್ತು ಪ್ರತಿ ಬಾರಿ ಲಾಗ್ ಒಂದೇ ಮಾರ್ಗವನ್ನು ಹೊಂದಿರುತ್ತದೆ. ನಾವು ತಾಂತ್ರಿಕವಾಗಿ ವಿಭಿನ್ನ ಕೋಡ್‌ಗಳನ್ನು ಚಲಾಯಿಸುತ್ತಿದ್ದರೂ - ಸಂದೇಶದ ಆವರ್ತನವು ವಿಭಿನ್ನವಾಗಿತ್ತು - ಸಿಸ್ಟಮ್‌ನ ನಡವಳಿಕೆಯು ಒಂದೇ ಆಗಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಈ ಲೋಡ್ ಸನ್ನಿವೇಶವು ಅದೇ ಸಮಸ್ಯೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತಿದೆ ಎಂದು ನಾವು ವಿಶ್ವಾಸ ಹೊಂದಿದ್ದೇವೆ.

ಅಭಿವ್ಯಕ್ತಿಗಳ ಅನುಕ್ರಮದಲ್ಲಿ ನಿರ್ಬಂಧಿಸುವಿಕೆಯು ನಿಖರವಾಗಿ ಎಲ್ಲಿ ಸಂಭವಿಸಿದೆ ಎಂಬುದನ್ನು ಈಗ ನಾವು ಲೆಕ್ಕಾಚಾರ ಮಾಡಬೇಕಾಗಿದೆ.

ಸಿಸ್ಟಮ್ನ ಈ ಅನುಷ್ಠಾನವು ಅಡಾ ಟಾಸ್ಕ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಬಳಸಿತು ಮತ್ತು ಅದನ್ನು ನಂಬಲಾಗದಷ್ಟು ಕಳಪೆಯಾಗಿ ಬಳಸಿತು. ಕಾರ್ಯಗಳು ಅದಾದಲ್ಲಿ ಉನ್ನತ ಮಟ್ಟದ ಏಕಕಾಲದಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ರಚನೆಯಾಗಿದ್ದು, ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯ ಥ್ರೆಡ್‌ಗಳಂತೆ, ಭಾಷೆಯಲ್ಲಿ ಮಾತ್ರ ನಿರ್ಮಿಸಲಾಗಿದೆ. ಎರಡು ಕಾರ್ಯಗಳು ಸಂವಹನ ನಡೆಸಬೇಕಾದಾಗ, ಅವರು "ಸಂಧಿಯನ್ನು ಹೊಂದಿಸುತ್ತಾರೆ", ಅಗತ್ಯ ಡೇಟಾವನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ ಮತ್ತು ನಂತರ ಸಂಧಿಸುವಿಕೆಯನ್ನು ನಿಲ್ಲಿಸುತ್ತಾರೆ ಮತ್ತು ಅವರ ಸ್ವತಂತ್ರ ಮರಣದಂಡನೆಗಳಿಗೆ ಹಿಂತಿರುಗುತ್ತಾರೆ. ಆದಾಗ್ಯೂ, ವ್ಯವಸ್ಥೆಯನ್ನು ವಿಭಿನ್ನವಾಗಿ ಅಳವಡಿಸಲಾಗಿದೆ. ಟಾರ್ಗೆಟ್ ಟಾಸ್ಕ್ ಅನ್ನು ಸಂಧಿಸಿದ ನಂತರ, ಆ ಟಾರ್ಗೆಟ್ ಟಾಸ್ಕ್ ಅನ್ನು ಮತ್ತೊಂದು ಟಾಸ್ಕ್ ನೊಂದಿಗೆ ರೆಂಡೆಜ್ವೌಸ್ ಮಾಡಲಾಯಿತು, ಅದು ಮೂರನೇ ಟಾಸ್ಕ್ ನೊಂದಿಗೆ ಸಂಧಿಸುತ್ತದೆ, ಮತ್ತು ಕೆಲವು ಪ್ರಕ್ರಿಯೆಗಳು ಪೂರ್ಣಗೊಳ್ಳುವವರೆಗೆ. ಇದರ ನಂತರ, ಈ ಎಲ್ಲಾ ಸಭೆಗಳು ಪೂರ್ಣಗೊಂಡವು ಮತ್ತು ಪ್ರತಿ ಕಾರ್ಯವು ಅದರ ಮರಣದಂಡನೆಗೆ ಮರಳಬೇಕಾಯಿತು. ಅಂದರೆ, ನಾವು ಪ್ರಪಂಚದ ಅತ್ಯಂತ ದುಬಾರಿ ಫಂಕ್ಷನ್ ಕರೆ ಸಿಸ್ಟಮ್‌ನೊಂದಿಗೆ ವ್ಯವಹರಿಸುತ್ತಿದ್ದೇವೆ, ಇದು ಇನ್‌ಪುಟ್ ಡೇಟಾದ ಭಾಗವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವಾಗ ಸಂಪೂರ್ಣ "ಬಹುಕಾರ್ಯಕ" ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿಲ್ಲಿಸಿತು. ಮತ್ತು ಈ ಮೊದಲು ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗಲಿಲ್ಲ ಏಕೆಂದರೆ ಥ್ರೋಪುಟ್ ತುಂಬಾ ಕಡಿಮೆಯಾಗಿದೆ.

ನಾನು ಈ ಕಾರ್ಯದ ಕಾರ್ಯವಿಧಾನವನ್ನು ವಿವರಿಸಿದ್ದೇನೆ ಏಕೆಂದರೆ ಸಂಧಿಸುವಿಕೆಯನ್ನು ವಿನಂತಿಸಿದಾಗ ಅಥವಾ ಪೂರ್ಣಗೊಳಿಸಲು ನಿರೀಕ್ಷಿಸಿದಾಗ, "ಟಾಸ್ಕ್ ಸ್ವಿಚ್" ಸಂಭವಿಸಬಹುದು. ಅಂದರೆ, ಪ್ರೊಸೆಸರ್ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸಿದ್ಧವಾಗಿರುವ ಮತ್ತೊಂದು ಕಾರ್ಯವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸಬಹುದು. ಒಂದು ಕಾರ್ಯವು ಮತ್ತೊಂದು ಕಾರ್ಯದೊಂದಿಗೆ ಭೇಟಿಯಾಗಲು ಸಿದ್ಧವಾದಾಗ, ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನವಾದ ಕಾರ್ಯವು ಕಾರ್ಯಗತಗೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಬಹುದು ಮತ್ತು ಅಂತಿಮವಾಗಿ ಮೊದಲ ಸಂಧಿಗೆ ಹಿಂತಿರುಗುವಿಕೆಯನ್ನು ನಿಯಂತ್ರಿಸಬಹುದು. ಮತ್ತು ಕಾರ್ಯವನ್ನು ಬದಲಾಯಿಸಲು ಕಾರಣವಾಗುವ ಇತರ ಘಟನೆಗಳು ಸಂಭವಿಸಬಹುದು; ಅಂತಹ ಒಂದು ಈವೆಂಟ್ ಮ್ಯೂಟೆಕ್ಸ್ ಅನ್ನು ಮುದ್ರಿಸುವುದು ಅಥವಾ ಕಾರ್ಯಗತಗೊಳಿಸುವಂತಹ ಸಿಸ್ಟಮ್ ಕಾರ್ಯಕ್ಕೆ ಕರೆಯಾಗಿದೆ.

ಯಾವ ಸಾಲಿನ ಕೋಡ್ ಸಮಸ್ಯೆಗೆ ಕಾರಣವಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ಕಾರ್ಯ ಸ್ವಿಚ್ ಅನ್ನು ಪ್ರಚೋದಿಸದೆಯೇ ಹೇಳಿಕೆಗಳ ಅನುಕ್ರಮದ ಮೂಲಕ ಪ್ರಗತಿಯನ್ನು ದಾಖಲಿಸುವ ಮಾರ್ಗವನ್ನು ನಾನು ಕಂಡುಹಿಡಿಯಬೇಕಾಗಿದೆ, ಇದು ಕ್ರ್ಯಾಶ್ ಸಂಭವಿಸುವುದನ್ನು ತಡೆಯುತ್ತದೆ. ಹಾಗಾಗಿ ಲಾಭ ಪಡೆಯಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ Put_Line()I/O ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಮಾಡುವುದನ್ನು ತಪ್ಪಿಸಲು. ನಾನು ಕೌಂಟರ್ ವೇರಿಯೇಬಲ್ ಅಥವಾ ಅದೇ ರೀತಿಯ ಏನನ್ನಾದರೂ ಹೊಂದಿಸಬಹುದು, ಆದರೆ ನಾನು ಅದನ್ನು ಪರದೆಯ ಮೇಲೆ ಪ್ರದರ್ಶಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ ಅದರ ಮೌಲ್ಯವನ್ನು ನಾನು ಹೇಗೆ ನೋಡಬಹುದು?

ಅಲ್ಲದೆ, ಲಾಗ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿದಾಗ, ಹೃದಯ ಬಡಿತದ ಸಂದೇಶಗಳ ಸಂಸ್ಕರಣೆಯಲ್ಲಿ ಫ್ರೀಜ್ ಹೊರತಾಗಿಯೂ, ಪ್ರಕ್ರಿಯೆಯ ಎಲ್ಲಾ I/O ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತದೆ ಮತ್ತು ಇತರ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ನಿರ್ವಹಿಸುವುದನ್ನು ತಡೆಯುತ್ತದೆ, ಇತರ ಸ್ವತಂತ್ರ ಕಾರ್ಯಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದನ್ನು ಮುಂದುವರೆಸಿದೆ. ಅಂದರೆ, ಕೆಲಸವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿರ್ಬಂಧಿಸಲಾಗಿಲ್ಲ, ಕಾರ್ಯಗಳ (ನಿರ್ಣಾಯಕ) ಸರಪಳಿ ಮಾತ್ರ.

ಇದು ತಡೆಯುವ ಅಭಿವ್ಯಕ್ತಿಯನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ಅಗತ್ಯವಾದ ಸುಳಿವು.

ನಾನು ಅಡಾ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಮಾಡಿದ್ದೇನೆ ಅದು ಕಾರ್ಯ, ಎಣಿಕೆಯ ಪ್ರಕಾರ ಮತ್ತು ಆ ಪ್ರಕಾರದ ಜಾಗತಿಕ ವೇರಿಯಬಲ್ ಅನ್ನು ಒಳಗೊಂಡಿದೆ. ಎಣಿಸಬಹುದಾದ ಅಕ್ಷರಗಳು ಸಮಸ್ಯಾತ್ಮಕ ಅನುಕ್ರಮದ ನಿರ್ದಿಷ್ಟ ಅಭಿವ್ಯಕ್ತಿಗಳಿಗೆ ಬದ್ಧವಾಗಿವೆ (ಉದಾ. Incrementing_Buffer_Index, Locking_Mutex, Mutex_Unlocked), ತದನಂತರ ಅದರಲ್ಲಿ ನಿಯೋಜನೆ ಅಭಿವ್ಯಕ್ತಿಗಳನ್ನು ಸೇರಿಸಲಾಗುತ್ತದೆ ಅದು ಜಾಗತಿಕ ವೇರಿಯಬಲ್‌ಗೆ ಅನುಗುಣವಾದ ಎಣಿಕೆಯನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ. ಈ ಎಲ್ಲದರ ಆಬ್ಜೆಕ್ಟ್ ಕೋಡ್ ಮೆಮೊರಿಯಲ್ಲಿ ಸ್ಥಿರತೆಯನ್ನು ಸಂಗ್ರಹಿಸಿರುವುದರಿಂದ, ಅದರ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯ ಪರಿಣಾಮವಾಗಿ ಕಾರ್ಯ ಸ್ವಿಚಿಂಗ್ ಅತ್ಯಂತ ಅಸಂಭವವಾಗಿದೆ. ಕಾರ್ಯವನ್ನು ಬದಲಾಯಿಸಬಹುದಾದ ಅಭಿವ್ಯಕ್ತಿಗಳ ಬಗ್ಗೆ ನಾವು ಪ್ರಾಥಮಿಕವಾಗಿ ಸಂಶಯ ಹೊಂದಿದ್ದೇವೆ, ಏಕೆಂದರೆ ಕಾರ್ಯವನ್ನು ಹಿಂತಿರುಗಿಸುವಾಗ (ಹಲವಾರು ಕಾರಣಗಳಿಗಾಗಿ) ಹಿಂತಿರುಗುವ ಬದಲು ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯ ಮೇಲೆ ನಿರ್ಬಂಧಿಸುವಿಕೆಯು ಸಂಭವಿಸಿದೆ.

ಟ್ರ್ಯಾಕಿಂಗ್ ಕಾರ್ಯವು ಸರಳವಾಗಿ ಲೂಪ್‌ನಲ್ಲಿ ಸಾಗಿತು ಮತ್ತು ಜಾಗತಿಕ ವೇರಿಯಬಲ್‌ನ ಮೌಲ್ಯವು ಬದಲಾಗಿದೆಯೇ ಎಂದು ನಿಯತಕಾಲಿಕವಾಗಿ ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ. ಪ್ರತಿ ಬದಲಾವಣೆಯೊಂದಿಗೆ, ಮೌಲ್ಯವನ್ನು ಫೈಲ್‌ಗೆ ಉಳಿಸಲಾಗಿದೆ. ನಂತರ ಒಂದು ಸಣ್ಣ ಕಾಯುವಿಕೆ ಮತ್ತು ಹೊಸ ಚೆಕ್. ನಾನು ಫೈಲ್‌ಗೆ ವೇರಿಯಬಲ್ ಅನ್ನು ಬರೆದಿದ್ದೇನೆ ಏಕೆಂದರೆ ಸಮಸ್ಯೆಯ ಪ್ರದೇಶದಲ್ಲಿ ಕಾರ್ಯವನ್ನು ಬದಲಾಯಿಸುವಾಗ ಸಿಸ್ಟಮ್ ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಆಯ್ಕೆ ಮಾಡಿದಾಗ ಮಾತ್ರ ಕಾರ್ಯವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿದೆ. ಈ ಕಾರ್ಯದಲ್ಲಿ ಏನೇ ಸಂಭವಿಸಿದರೂ ಇತರ, ಸಂಬಂಧವಿಲ್ಲದ ನಿರ್ಬಂಧಿಸಲಾದ ಕಾರ್ಯಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ.

ಸಿಸ್ಟಮ್ ಸಮಸ್ಯಾತ್ಮಕ ಕೋಡ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಹಂತವನ್ನು ತಲುಪಿದಾಗ, ಪ್ರತಿ ಮುಂದಿನ ಅಭಿವ್ಯಕ್ತಿಗೆ ಚಲಿಸುವಾಗ ಜಾಗತಿಕ ವೇರಿಯಬಲ್ ಅನ್ನು ಮರುಹೊಂದಿಸಲಾಗುತ್ತದೆ ಎಂದು ನಿರೀಕ್ಷಿಸಲಾಗಿದೆ. ನಂತರ ಏನಾದರೂ ಸಂಭವಿಸುತ್ತದೆ ಅದು ಕಾರ್ಯವನ್ನು ಬದಲಾಯಿಸಲು ಕಾರಣವಾಗುತ್ತದೆ ಮತ್ತು ಅದರ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯ ಆವರ್ತನ (10 Hz) ಮಾನಿಟರಿಂಗ್ ಕಾರ್ಯಕ್ಕಿಂತ ಕಡಿಮೆಯಿರುವುದರಿಂದ, ಮಾನಿಟರ್ ಜಾಗತಿಕ ವೇರಿಯಬಲ್‌ನ ಮೌಲ್ಯವನ್ನು ಸೆರೆಹಿಡಿಯಬಹುದು ಮತ್ತು ಅದನ್ನು ಬರೆಯಬಹುದು. ಸಾಮಾನ್ಯ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ನಾನು ಎಣಿಕೆಗಳ ಉಪವಿಭಾಗದ ಪುನರಾವರ್ತಿತ ಅನುಕ್ರಮವನ್ನು ಪಡೆಯಬಹುದು: ಕಾರ್ಯ ಸ್ವಿಚ್‌ನ ಸಮಯದಲ್ಲಿ ವೇರಿಯಬಲ್‌ನ ಕೊನೆಯ ಮೌಲ್ಯಗಳು. ನೇತಾಡುವಾಗ, ಜಾಗತಿಕ ವೇರಿಯೇಬಲ್ ಇನ್ನು ಮುಂದೆ ಬದಲಾಗಬಾರದು ಮತ್ತು ಕೊನೆಯದಾಗಿ ಬರೆದ ಮೌಲ್ಯವು ಯಾವ ಅಭಿವ್ಯಕ್ತಿ ಪೂರ್ಣಗೊಂಡಿಲ್ಲ ಎಂಬುದನ್ನು ಸೂಚಿಸುತ್ತದೆ.

ನಾನು ಟ್ರ್ಯಾಕಿಂಗ್‌ನೊಂದಿಗೆ ಕೋಡ್ ಅನ್ನು ರನ್ ಮಾಡಿದ್ದೇನೆ. ಅವನು ಹೆಪ್ಪುಗಟ್ಟಿದ. ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆ ಗಡಿಯಾರದ ಕೆಲಸದಂತೆ ಕೆಲಸ ಮಾಡಿದೆ.

ಲಾಗ್ ನಿರೀಕ್ಷಿತ ಅನುಕ್ರಮವನ್ನು ಹೊಂದಿದೆ, ಇದು ಮ್ಯೂಟೆಕ್ಸ್ ಎಂದು ಕರೆಯಲಾಗಿದೆ ಎಂದು ಸೂಚಿಸುವ ಮೌಲ್ಯದಿಂದ ಅಡ್ಡಿಪಡಿಸಲಾಗಿದೆ Unlock, ಮತ್ತು ಕಾರ್ಯವು ಪೂರ್ಣಗೊಂಡಿಲ್ಲ - ಸಾವಿರಾರು ಹಿಂದಿನ ಕರೆಗಳಂತೆಯೇ.

ಅಪೆಕ್ಸ್ ಇಂಜಿನಿಯರ್‌ಗಳು ಈ ಸಮಯದಲ್ಲಿ ತಮ್ಮ ಕೋಡ್ ಅನ್ನು ತೀವ್ರವಾಗಿ ವಿಶ್ಲೇಷಿಸುತ್ತಿದ್ದರು ಮತ್ತು ಸೈದ್ಧಾಂತಿಕವಾಗಿ ಲಾಕ್ ಸಂಭವಿಸಬಹುದಾದ ಸ್ಥಳವನ್ನು ಮ್ಯೂಟೆಕ್ಸ್‌ನಲ್ಲಿ ಕಂಡುಕೊಂಡರು. ಆದರೆ ಅದರ ಸಂಭವನೀಯತೆಯು ತುಂಬಾ ಕಡಿಮೆಯಾಗಿದೆ, ಏಕೆಂದರೆ ಒಂದು ನಿರ್ದಿಷ್ಟ ಸಮಯದಲ್ಲಿ ಸಂಭವಿಸುವ ಘಟನೆಗಳ ನಿರ್ದಿಷ್ಟ ಅನುಕ್ರಮವು ನಿರ್ಬಂಧಿಸಲು ಕಾರಣವಾಗಬಹುದು. ಮರ್ಫಿಯ ಕಾನೂನು, ಹುಡುಗರೇ, ಇದು ಮರ್ಫಿಯ ಕಾನೂನು.

ನನಗೆ ಅಗತ್ಯವಿರುವ ಕೋಡ್‌ನ ತುಣುಕನ್ನು ರಕ್ಷಿಸಲು, ಆ ತುಣುಕಿಗೆ ಮ್ಯೂಟೆಕ್ಸ್ ಪ್ರವೇಶವನ್ನು ನಿಯಂತ್ರಿಸಲು ನಾನು ಮ್ಯೂಟೆಕ್ಸ್ ಫಂಕ್ಷನ್ ಕರೆಗಳನ್ನು (OS ಮ್ಯೂಟೆಕ್ಸ್ ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಮೇಲೆ ನಿರ್ಮಿಸಲಾಗಿದೆ) ಸಣ್ಣ ಸ್ಥಳೀಯ ಅಡಾ ಮ್ಯೂಟೆಕ್ಸ್ ಪ್ಯಾಕೇಜ್‌ನೊಂದಿಗೆ ಬದಲಾಯಿಸಿದೆ.

ನಾನು ಅದನ್ನು ಕೋಡ್‌ಗೆ ಸೇರಿಸಿದೆ ಮತ್ತು ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸಿದೆ. ಏಳು ಗಂಟೆಗಳ ನಂತರ ಕೋಡ್ ಇನ್ನೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ.

ನನ್ನ ಕೋಡ್ ಅನ್ನು ತರ್ಕಬದ್ಧವಾಗಿ ಸಲ್ಲಿಸಲಾಯಿತು, ಅಲ್ಲಿ ಅವರು ಅದನ್ನು ಕಂಪೈಲ್ ಮಾಡಿದರು, ಅದನ್ನು ಡಿಸ್ಅಸೆಂಬಲ್ ಮಾಡಿದರು ಮತ್ತು ಸಮಸ್ಯಾತ್ಮಕ ಮ್ಯೂಟೆಕ್ಸ್ ಕಾರ್ಯಗಳಲ್ಲಿ ಬಳಸಿದ ಅದೇ ವಿಧಾನವನ್ನು ಅದು ಬಳಸುವುದಿಲ್ಲ ಎಂದು ಪರಿಶೀಲಿಸಿದರು.

ಇದು ನನ್ನ ವೃತ್ತಿಜೀವನದ ಅತ್ಯಂತ ಕಿಕ್ಕಿರಿದ ಕೋಡ್ ವಿಮರ್ಶೆಯಾಗಿದೆ 🙂 ನನ್ನೊಂದಿಗೆ ಕೋಣೆಯಲ್ಲಿ ಸುಮಾರು ಹತ್ತು ಎಂಜಿನಿಯರ್‌ಗಳು ಮತ್ತು ವ್ಯವಸ್ಥಾಪಕರು ಇದ್ದರು, ಇನ್ನೂ ಹತ್ತು ಜನರು ಕಾನ್ಫರೆನ್ಸ್ ಕರೆಯಲ್ಲಿದ್ದರು - ಮತ್ತು ಅವರೆಲ್ಲರೂ ಸುಮಾರು 20 ಸಾಲುಗಳ ಕೋಡ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿದರು.

ಕೋಡ್ ಅನ್ನು ಪರಿಶೀಲಿಸಲಾಗಿದೆ, ಹೊಸ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದಾದ ಫೈಲ್‌ಗಳನ್ನು ಜೋಡಿಸಲಾಗಿದೆ ಮತ್ತು ಔಪಚಾರಿಕ ರಿಗ್ರೆಶನ್ ಪರೀಕ್ಷೆಗಾಗಿ ಸಲ್ಲಿಸಲಾಗಿದೆ. ಒಂದೆರಡು ವಾರಗಳ ನಂತರ, ಕೌಂಟ್‌ಡೌನ್ ಪರೀಕ್ಷೆ ಯಶಸ್ವಿಯಾಗಿದೆ ಮತ್ತು ರಾಕೆಟ್ ಹಾರಿತು.

ಸರಿ, ಅದು ಚೆನ್ನಾಗಿದೆ, ಆದರೆ ಕಥೆಯ ಅರ್ಥವೇನು?

ಇದು ಸಂಪೂರ್ಣವಾಗಿ ಅಸಹ್ಯಕರ ಸಮಸ್ಯೆಯಾಗಿತ್ತು. ನೂರಾರು ಸಾವಿರ ಸಾಲುಗಳ ಕೋಡ್, ಸಮಾನಾಂತರ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ, ಹನ್ನೆರಡು ಸಂವಾದಾತ್ಮಕ ಪ್ರಕ್ರಿಯೆಗಳು, ಕಳಪೆ ವಾಸ್ತುಶಿಲ್ಪ ಮತ್ತು ಕಳಪೆ ಅನುಷ್ಠಾನ, ಎಂಬೆಡೆಡ್ ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ಇಂಟರ್ಫೇಸ್‌ಗಳು ಮತ್ತು ಲಕ್ಷಾಂತರ ಡಾಲರ್‌ಗಳನ್ನು ಖರ್ಚು ಮಾಡಲಾಗಿದೆ. ಒತ್ತಡವಿಲ್ಲ, ಸರಿ.

ನಾನು ಪೋರ್ಟಿಂಗ್ ಮಾಡುತ್ತಿರುವುದರಿಂದ ನಾನು ಗಮನ ಸೆಳೆದಿದ್ದರೂ ಈ ಸಮಸ್ಯೆಯಲ್ಲಿ ನಾನು ಮಾತ್ರ ಕೆಲಸ ಮಾಡಲಿಲ್ಲ. ಆದರೆ ನಾನು ಅದನ್ನು ಮಾಡಿದರೂ ಸಹ, ನಾನು ನೂರಾರು ಸಾವಿರ ಸಾಲುಗಳ ಕೋಡ್ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ ಅಥವಾ ಅವುಗಳನ್ನು ಸ್ಕಿಮ್ ಮಾಡಿದ್ದೇನೆ ಎಂದು ಅರ್ಥವಲ್ಲ. ಕೋಡ್ ಮತ್ತು ಲಾಗ್‌ಗಳನ್ನು ದೇಶಾದ್ಯಂತ ಎಂಜಿನಿಯರ್‌ಗಳು ವಿಶ್ಲೇಷಿಸಿದ್ದಾರೆ, ಆದರೆ ವೈಫಲ್ಯದ ಕಾರಣಗಳ ಬಗ್ಗೆ ಅವರು ತಮ್ಮ ಊಹೆಗಳನ್ನು ಹೇಳಿದಾಗ, ಅವುಗಳನ್ನು ನಿರಾಕರಿಸಲು ನನಗೆ ಅರ್ಧ ನಿಮಿಷ ಮಾತ್ರ ಬೇಕಾಯಿತು. ಮತ್ತು ಸಿದ್ಧಾಂತಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಲು ನನ್ನನ್ನು ಕೇಳಿದಾಗ, ನಾನು ಅದನ್ನು ಬೇರೆಯವರಿಗೆ ವರ್ಗಾಯಿಸುತ್ತೇನೆ, ಏಕೆಂದರೆ ಈ ಎಂಜಿನಿಯರ್‌ಗಳು ತಪ್ಪು ದಾರಿಯಲ್ಲಿ ಹೋಗುತ್ತಿದ್ದಾರೆ ಎಂಬುದು ನನಗೆ ಸ್ಪಷ್ಟವಾಗಿದೆ. ಅಹಂಕಾರದ ಧ್ವನಿ? ಹೌದು, ಇದು ನಿಜ, ಆದರೆ ನಾನು ಇನ್ನೊಂದು ಕಾರಣಕ್ಕಾಗಿ ಊಹೆಗಳನ್ನು ಮತ್ತು ವಿನಂತಿಗಳನ್ನು ತಿರಸ್ಕರಿಸಿದೆ.

ನಾನು ಸಮಸ್ಯೆಯ ಸ್ವರೂಪವನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ. ಇದು ಎಲ್ಲಿ ನಡೆಯುತ್ತಿದೆ ಅಥವಾ ಏಕೆ ಎಂದು ನನಗೆ ನಿಖರವಾಗಿ ತಿಳಿದಿರಲಿಲ್ಲ, ಆದರೆ ಏನಾಗುತ್ತಿದೆ ಎಂದು ನನಗೆ ತಿಳಿದಿತ್ತು.

ವರ್ಷಗಳಲ್ಲಿ, ನಾನು ಸಾಕಷ್ಟು ಜ್ಞಾನ ಮತ್ತು ಅನುಭವವನ್ನು ಸಂಗ್ರಹಿಸಿದೆ. ನಾನು ಅಡಾವನ್ನು ಬಳಸುವ ಪ್ರವರ್ತಕರಲ್ಲಿ ಒಬ್ಬನಾಗಿದ್ದೆ ಮತ್ತು ಅದರ ಅನುಕೂಲಗಳು ಮತ್ತು ಅನಾನುಕೂಲಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ. ಅದಾ ರನ್‌ಟೈಮ್ ಲೈಬ್ರರಿಗಳು ಕಾರ್ಯಗಳನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತವೆ ಮತ್ತು ಸಮಾನಾಂತರ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಯನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುತ್ತವೆ ಎಂದು ನನಗೆ ತಿಳಿದಿದೆ. ಮತ್ತು ಮೆಮೊರಿ, ರೆಜಿಸ್ಟರ್‌ಗಳು ಮತ್ತು ಅಸೆಂಬ್ಲರ್ ಮಟ್ಟದಲ್ಲಿ ಕಡಿಮೆ ಮಟ್ಟದ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಅನ್ನು ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ನನ್ನ ಕ್ಷೇತ್ರದಲ್ಲಿ ನನಗೆ ಆಳವಾದ ಜ್ಞಾನವಿದೆ. ಮತ್ತು ಸಮಸ್ಯೆಯ ಕಾರಣವನ್ನು ಕಂಡುಹಿಡಿಯಲು ನಾನು ಅವುಗಳನ್ನು ಬಳಸಿದ್ದೇನೆ. ನಾನು ಕೇವಲ ದೋಷದ ಸುತ್ತಲೂ ಕೆಲಸ ಮಾಡಲಿಲ್ಲ, ಬಹಳ ಸೂಕ್ಷ್ಮವಾದ ರನ್ಟೈಮ್ ಪರಿಸರದಲ್ಲಿ ಅದನ್ನು ಹೇಗೆ ಕಂಡುಹಿಡಿಯುವುದು ಎಂದು ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ.

ಅಂತಹ ಹೋರಾಟದ ವೈಶಿಷ್ಟ್ಯಗಳು ಮತ್ತು ಪರಿಸ್ಥಿತಿಗಳ ಬಗ್ಗೆ ತಿಳಿದಿಲ್ಲದವರಿಗೆ ಕೋಡ್ನೊಂದಿಗೆ ಹೋರಾಟದ ಇಂತಹ ಕಥೆಗಳು ತುಂಬಾ ಆಸಕ್ತಿದಾಯಕವಲ್ಲ. ಆದರೆ ನಿಜವಾಗಿಯೂ ಕಷ್ಟಕರವಾದ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಏನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಈ ಕಥೆಗಳು ನಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತವೆ.

ನಿಜವಾಗಿಯೂ ಕಠಿಣ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು, ನೀವು ಕೇವಲ ಪ್ರೋಗ್ರಾಮರ್ಗಿಂತ ಹೆಚ್ಚಿನದಾಗಿರಬೇಕು. ಕೋಡ್ನ "ವಿಧಿ", ಅದರ ಪರಿಸರದೊಂದಿಗೆ ಅದು ಹೇಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ ಮತ್ತು ಪರಿಸರವು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು.

ತದನಂತರ ನೀವು ನಿಮ್ಮ ಸ್ವಂತ ಹಾಳಾದ ರಜೆಯ ವಾರವನ್ನು ಹೊಂದಿರುತ್ತೀರಿ.

ಮುಂದುವರೆಯಲು.

ಮೂಲ: www.habr.com