人生中盤から色々学ぶ(ブ)ログ -3ページ目

人生中盤から色々学ぶ(ブ)ログ

IT、経済、英語、その他今必要だなと思う事を学びつつ、自分用の記録ついでにブログ化。
あん時やっときゃ良かった、をそろそろ終わりにしたい!

■WindowsのOS情報を知りたい時

 

ver

>ver
Microsoft Windows [Version 10.0.19044.1826]

 

wmic os get caption

>wmic os get caption
Caption
Microsoft Windows 10 Pro

 

wmic os get osarchitecture

>wmic os get osarchitecture
OSArchitecture
64 ビット

 

 

 

 

■Excelでペーストした後に表示される邪魔なメニューを消し去りたい時

 

 

1.[ファイル] タブをクリックし、[オプション] をクリック

2.[詳細設定]カテゴリ > [切り取り、コピー、貼り付け] 

3.[コンテンツを貼り付けるときに [貼り付けオプションを表示する] チェック ボックスをオフにする

 

 

 

 

■古いCPUと新しいCPUの性能を同一指標で比較したい時

 

 

 

CPUmarkが便利。

5年前に導入したサーバと今回導入予定のサーバのCPU性能比較をする際に重宝しました。

(昔はspecintなんかでやってたのですが、新旧のCPUが同時に掲載されていないケースもあるので…)

 

 

 

 

久しぶりにAIXを扱う案件を前に記憶の掘り起こしを兼ねて、過去の案件で使った資料を確認中です。

 

システムバックアップ(mksysb)で取得したバックアップデータをリストアした後、リストア後状態の正常性確認の為にこんな情報を取得してました。

 

 

df -k /tmp

バックアップ時にtmp領域に空きがないと失敗します。

lsattr -El sys0

sys0デバイスの設定状態確認の為


lspv
ディスク情報確認の為。特に共有デバイスがある場合はPVIDも重要になります。

lsdev -C
デバイス情報確認の為。

ls -l /dev

デバイスファイル情報の確認。定義のみで有効化していないデバイスのファイルは作成されなかった?

odmget CuAt
AIX独自だと思いますが、ややこしいODM情報の取得。Windowsのレジストリのようなものと認識しています。一つ一つの意味は把握していません。

sysdumpdev -l

ダンプデバイスの確認。だいたいシステムディスクはミラーリングしているので、ダンプデバイスがどちらに存在するか確認しています。

lsps -a
ページングスペース情報確認の為。ダンプデバイスと似た理由で取得していたような…

lsfs -a

ファイルシステム情報。

lsvg -l ルートtvg | grep -v 'N/A'
システムルートのVGにマウントしているLVのリスト情報。

grep RECOVER_DEVICES /bosinst.data
リストア時のODM情報復旧についての定義の確認。


lsdev -Cc tape
lsattr -El rmt0 -a block_size

mksysbのバックアップ取得先となるテープの情報。ブロックサイズは1024にしておく必要(があったような)


find ./ | grep -f /etc/exclude.rootvg

バックアップ除外対象のファイルシステムを確認。

この結果にバックアップが必要なファイルシステムが含まれていた場合、リストア時に顔が引きつる事になります。

 

今回はこれで終わり。

内容もあやふやで間違いもありそうに思いますので、確認が取れたものから修正していきたいとおもいます。

 

メモ程度ですが。

 

昔からお付き合いのある企業様のシステムでは結構な台数のモデムでEDI通信をしています。

 

モデム自体生産終了となるなどEDI関連はレガシー過ぎて大変な状況ですね。

 

そこに、ずっと昔から言われていたISDNの終了がとうとう目前に迫って参りました。

 

 

 

上記はNTT西の情報ですが、通話利用に関しては問題ない形で切り替えられるようです。

 

工事不要、番号も電話機も継続利用可能。しかも遠距離通話は安くなります。

 

 

 

EDI的に問題となるのはこちらの話ですね。

 

 

 

 

ディジタル通信モードは2024年1月にサービスを終了、この部分です。

 

EDIに特化した移行イメージについても以下のような記載があります。

 

 

 

移行方式の検討の目安、といった所でしょうか。

 

どのような方式を採るにせよ、EDI通信には必ず相手が居ます。

 

その為、通信相手先となる企業様にも連動してシステム変更頂く必要があります。

 

相手先企業とのシステム変更のタイミングや方式などの調整、これが一番難航しそうな部分だと感じます・・・

 

 

 

 

また、2024年の切り替えに間に合わない場合の救済策も一応NTT側で準備して頂いているようです。

 

前述の「INSネットをご利用の事業者様へ」のページ内最下段にその内容が記載されています。

 

通信データをIP網の入口と出口で変換する方式となるようです。カプセル化して後で復号するという事でしょうか。

 

この場合は、全て今まで通りの環境(ソフト・機材)でEDI通信が可能なようです。

 

 

 

問題は「処理時間が増加する場合がある」の一文。

 

この部分をしっかりテストしておく必要があります。

 

伝送可否の疎通レベルではなく、実際の業務データを用いた時間測定ですね。

 

 

多くの場合、1本の電話回線は1つの処理のみで占有するのではなく、時間帯別に複数の処理で利用していると思います。

 

10時にA社への送信、12時にB社からの受信、15時にA社からの受信、18時にC社への送信、などのように。

 

処理時間が秒レベルで延びる程度なら賄える範囲になりそうですが、数倍レベルになると30分が3時間などのケースも有り得ます。

 

このような場合、別の空き回線に処理を振り替える、または回線を追加する等の施策が必要になります。

 

システム設定変更で別の回線に処理を振り替える作業も必要になりますね。場合によっては処理スクリプトの変更も。

 

 

 

確実に終わる事が見えているサービスの回線を追加(そもそも出来ないかも?)などというバカげた話は有り得ません。

 

その場合は即座に切り替え計画を立てて、予算稟議をあげ、相手先企業と調整をして、と、泥沼化しそうです(笑)

 

 

 

 

やはりここは、最初から変更の方向で計画を立てる必要がある局面なのでしょう。

 

 

 

 

EDIの移行に関するサービスを提供されている企業様も存在するようです。

 

今回の件で参考にさせて頂いたサイト様の記事URLを記載します。