@Macarlo, Inc.

Esta seção se destina a esclarecer algumas das mais freqüentes dúvidas que aparecem no dia-a-dia dos que trabalham com OS/2, principalmente para os que estão entrando agora no mundo do Warp. As informações aqui contidas são de usuários de OS/2, como eu e você, e não representam de modo algum a opinião oficial da IBM sobre o assunto. Se você tiver alguma colaboração a dar, mande para o meu e-mail que será benvinda e colocada aqui.

@Macarlo

FREQUENTLY ASKED QUESTIONS

COMO ATUALIZAR O WIN32
Procedimento para remover win 32 antes de instalar o w32s125.exe:
(válido para Warp 4)

1. Remova na seção [386Enh] do arquivo SYSTEM.INI o seguinte comando:

file:device=<WINDOWS>\<SYSTEM>\win32s\w32s.386
Onde <WINDOWS> e <SYSTEM> são os locais onde estão os
diretórios Windows and System, respectivamente.

2. Remova na seção [BOOT] do arquivo SYSTEM.INI o seguinte comando:
Remova a palavra winmm16.dll da seguinte linha

drivers=mmsystem.dll winmm16.dll

3. Apague os seguintes arquivos do diretório os2\mdos\winos2\system:

W32SYS.DLL
WIN32S16.DLL
WIN32S.INI

4.Apague todos os arquivos do diretório
os2\mdos\winos2\system\WIN32S
e em seguida remova este diretório.

5.Feche e reabra a sessão WINOS/2.

COMO APLICAR O FIX 4 PARA O WARP 4.0

É um procedimento relativamente simples. Na realidade gasta-se mais
tempo com a preparação dos disquetes do que com a aplicação do pacote
corretivo propriamente dito. Não se deixe impressionar com o volume de
informações dos Readme's que acompanham estes pacotes. Isto é igual a
bula de remédio. Se você comecar a analisar tantas contra-indicações e
efeitos colaterais acabará nao tomando o remédio. O importante é que
você tenha em mente que:
-a aplicação de FP's é importante porque eles além de eliminar bugs,
muitas vezes adicionam novos recursos ao sistema;
-qualquer FP sempre acaba gerando novos bugs, isto é normal;
-qualquer aplicação de FP pode ser facilmente revertida.

Mas vamos lá:

Seguindo o padrão da IBM, os FP's são distribuidos na forma de arquivos
"imagem" de disquete, aqueles com aquela extensão *.*dk. Portanto, a
primeira providência a tomar é verificar se voce já tem o programa
LOADDSKF.EXE que permitirá gerar os disquetes a partir destes arquivos.
Sugiro que você dê um dir loaddskf.exe /s na linha de comando de uma
sessão de janela do OS/2 para verificar. Se não encontrá-lo poderá
baixá-lo de ftp://ftp.boulder.ibm.com/ps/tools/loaddskf/loaddskf.exe
Depois copie o LOADDSKF.EXE para o diretório C:\OS2 ou para qualquer
outro que esteja no PATH.

Os FixPack's antigamente eram distribuídos pela IBM já incluindo dois
arquivos "imagem" para a geração dos disquetes do programa utilitário de
correção, o Corrective Service Facility (CSF). Este programa é que
possibilita a aplicação de pacotes de correções no sistema. Portanto,
antes de mais nada verifique se você tem os arquivos CSFBOOT.1DK e
CSFBOOT.2DK. Caso nao os tenha, eles estão disponíveis em um pacote com o
nome WKICKR.ZIP em ftp://ftp.boulder.ibm.com/ps/products/os2/fixes/wkickr
( a versão em inglês) e tem tambem uma versão em português no BBS da IBM
Brasil (011 889-0065)

Vamos agora gerar os disquetes com o LOADDSKF.EXE. Começando com os
arquivos do programa utilitário de correção (CSF). Coloque um disquete
no drive A (não precisa estar vazio ou formatado), abra uma sessão de
janela (ou tela) do OS/2 e digite na linha de comando:

LOADDSKF CSFBOOT.1DK A: /F

Inicialmente você vai receber uma mensagem dizendo que os dados existentes
no disquete serão perdidos...etc (ele vai ser formatado) e pedindo a
confirmação para a continuidade do processo. Confirme para que o processo
continue e o disquete seja gerado.

Agora, algo muito importante! No final você deverá receber, junto com um
bip, uma mensagem dizendo que o disquete foi gerado com sucesso... Se isto
não ocorrer é porque o arquivo imagem *.*dk está com problemas. Você
terá de baixá-lo novamente. De nenhum modo tente utilizar o disquete assim
gerado com uma mensagem final de erro. Infelizmente é bastante comum
(com as nossas linhas telefônicas) acontecer isto com arquivos *.*dk
baixados por FTP e por ZMODEM também.

Agora faça o mesmo com o arquivo CSFBOOT.2DK para gerar o segundo disquete
do programa utilitário.

Você vai repetir esta operação para todos os arquivos *.*DK do pacote de
correção, ou seja, para os nove arquivos XRBM001.1DK.....XRBM001.9DK que
compõem o FP 1 do OS/2 Warp 4. No total você vai ficar com onze disquetes,
ou seja, dois do CSF e nove do FP1. Nao esqueça de ir etiquetando-os como
por exemplo, CSF 1/2, CSF 2/2, CSD 1/9, CSD 2/9....etc.

Vamos agora para a aplicação do Fix Pack. Existem dois métodos mas me
limitarei a falar do que permite um melhor acompanhamento do que está
sendo feito. O outro método faz uso de um boot a partir dos disquetes do
CSF (esta é a razão do nome CSFBOOT).

1- Rode o CHKDSK <drive:> /F em todos os HD's (e/ou particoes).Na partição
de boot voce terá de fazê-lo atraves de um boot com os disquetes de
instalação do OS/2 (ou entao com os disquetes gerados pelo "Criar
Disquetes de Utilitarios"). Em qualquer uma das opções você vai precisar
ter em um disquete o CHKDSK.EXE e o UHPFS.DLL para poder rodar o CHKDSK.
Uma outra forma, não muito profissional, é voce forçar um CHKDSK /F
desligando a máquina sem fazer o shutdown e em seguida religando.
Independentemente da forma que você escolha é importante que o CHKDSK /F
seja rodado para que eventuais erros existentes no sistema de arquivos
não permaneçam.

2- Coloque o disquete 1 do utilitário CSF no drive A e feche todos os
programas que eventualmente estejam rodando.

3- Abra uma sessão de janela do OS/2 e digite na linha de comando...
A:\SERVICE e em seguida tecle ENTER

4- O utilitário CSF abrirá a sua janela principal com uma pequena janela
no centro "Select Source Drive" com a opção Drive A selecionada que
deverá ser confirmada com um OK.

5- Será solicitada então a remoção do disquete e a colocação do disquete 2
do CSF. Uma vez feito isso, dê um clique em OK.

6- Em seguida será solicitada a remoção do disquete 2 do CSF e a colocação
do primeiro disquete do FixPack, ou seja, o que etiquetamos como CSD 1/9.
Feito isto e dado um clique no OK, o sistema começará a ser vasculhado
em busca de arquivos passíveis de correção. Atenção! Isto pode demorar
um pouco. Tenha paciencia.

7- A janela principal do CSF se abrirá mostrando os produtos corrigíveis
(Serviceable Products). Até o Warp 3 o sistema base do OS/2 era
tratado de forma separada do MMOS2 (o suporte de multimidia do OS/2) de
forma que eram tratados pelo CSF como produtos distintos para efeito da
aplicação de correções. No caso do Warp 4 (Merlin) os dois passaram a
ser um unico produto e portanto nao haverá mais de um produto a ser
escolhido. De um clique no botão "Correção" para que o processo
continue.

8- Agora será aberta uma janela com três colunas. Na primeira coluna está
o produto a ser corrigido. Na segunda coluna deverá ser especificado
um diretório que servirá de repositório para o armazenamento dos
arquivos (já comprimidos) da instalação original do OS/2 que serão
substituídos pelos do FixPack, como por exemplo, C:\OS2ORIG. Atenção,
utilize um diretório especifico para isto e lembre-se que deverá haver
espaco suficiente no(s) disco(s)(7 a 12 MB). A terceira coluna "Backup"
não tem nenhuma função no caso de primeiro fix sendo aplicado. Dê um
clique no OK para prosseguir.

9- Você agora vai ver uma lista de arquivos que devem ser substituídos, mas
como estão em uso pelo sistema (locked) a substituição deverá ser
feita posteriormente (deferring). Duas opções são apresentadas
"Continue" ou "Reboot". Clique em "Continue".

10-Daqui em diante é só seguir as solicitações de troca dos disquetes,
lembrando que qualquer pergunta referente à substituição de um
determinado arquivo devera' sempre ser respondida afirmativamente.
Quando o último disquete for processado feche a janela do CSF, encerre
o OS/2 e dê um boot.

11-Agora, quando o sistema estiver sendo carregado aqueles arquivos que
estavam bloqueados serão substituidos e o sistema fará' um segundo boot
automaticamente para completar o processo.

Enquanto você mantiver o diretório do repositório dos arquivos da
instalação original é possivel restaurar a configuração original. Somente
elimine estes arquivos quando tiver certeza de que o sistema está
funcionando a contento. A mudança destes arquivos para outro local também
impossiblitará a localização dos mesmos pelo CSF para uma eventual
restauração.

Lembre-se tambem que este FixPack é aplicado somente ao sistema base e
MMOS2. As correções para o TCP/IP por exemplo, são feitas por pacotes
específicos.

AbraçOS/2

Renee

**************************************************************
Renee Senger <rsenger@pobox.com>
Curitiba - PR - Brazil
**************************************************************

FIX 4: E SE ALGO NÃO DER CERTO?

Se algo der errado após a aplicação do Fix 4, não se assuste, mesmo que a PM se torne aparentemente inacessível. Basta editar a RESPONSE.FIL existente no SP Disk 2 , dar o boot, entrar no prompt e rodar o backout, que tudo será restaurado. Como fazer isso? Você dá o boot e entra na linha de comando pela opção F2 da tela obtida com Alt+F1 quando aparece o quadradinho branco no canto superior esquerdo do monitor, ou, se não conseguir acessar a opção F2, dê o boot com os utilitários do Warp. Coloque o disco 1 do CSF no drive A e digite A:\SERVICE; coloque o disco 2 do CSF quando solicitado e, finalmente, o disco 1 do FP. Você vai ter, então, aqela tela do CSF com o(s) produto(s) passível(eis) de ser(em) corrigido(s). Neste ponto você clica no botão na parte inferior da janela para alterar a lista de produtos e escolhe produtos gravados. Agora é só dar um clique em reposição e o CSF vai fazer tudo voltar ao que era antes.

Abaixo, alguns exemplos de RESPONSE.FIL, para várias situações:

* This is a sample response file which can be used when applying service
* for the first time using FSERVICE when there is no existing
* archive of the product being serviced.
* It will service all partitions, and place an archive in each partition.
* It does not take a backup of changed files.
*
* :LOGFILE C:\OS2\INSTALL\SERVICE.LOG
:FLAGS REPLACE_PROTECTED REPLACE_NEWER
:SOURCE A:\
:SERVICE
:SYSLEVEL \OS2\INSTALL\SYSLEVEL.OS2
:ARCHIVE \ARCHIVE
:SERVICE
:SYSLEVEL \MMOS2\INSTALL\SYSLEVEL.MPM
:ARCHIVE \ARCHIVE
*
* End of sample SERVICE response file without backup.
*
**********************************************************************
*
* This is a sample response file to be used when applying service
* using FSERVICE when there is an existing archive of the product
* being serviced. This demonstrates the ability to take a backup
* of changed files.
*
* :LOGFILE C:\OS2\INSTALL\SERVICE.LOG
* :FLAGS REPLACE_PROTECTED REPLACE_NEWER
* :SOURCE A:\
* :SERVICE
* :SYSLEVEL C:\OS2\INSTALL\SYSLEVEL.OS2
* :ARCHIVE C:\ARCHIVE
* :BACKUP C:\BACKUP
* :SERVICE
* :SYSLEVEL C:\MMOS2\INSTALL\SYSLEVEL.MPM
* :ARCHIVE C:\ARCHIVE
* :BACKUP C:\BACKUPM
*
* End of sample SERVICE response file with backup.
*
**********************************************************************
*
* This is a sample response file to be used when backing out to the
* archive level of a product.
*
* :LOGFILE C:\OS2\INSTALL\SERVICE.LOG
* :TARGET ARCHIVE
* :BACKOUT
* :SYSLEVEL C:\OS2\INSTALL\SYSLEVEL.OS2
* :BACKOUT
* :SYSLEVEL C:\MMOS2\INSTALL\SYSLEVEL.MPM
*
* Note: You may need to leave an uncommented blank line after the
* last :SYSLEVEL line when backing out.
*
* End of sample BACKOUT to archive response file.
*
**********************************************************************
*
* This is a sample response file to be used when backing out to the
* backup level of a product.
*
* :LOGFILE C:\OS2\INSTALL\SERVICE.LOG
* :TARGET BACKUP
* :BACKOUT
* :SYSLEVEL C:\OS2\INSTALL\SYSLEVEL.OS2
* :BACKOUT
* :SYSLEVEL C:\MMOS2\INSTALL\SYSLEVEL.MPM
*
* End of sample BACKOUT to backup response file.
*
**********************************************************************
*
* This is a sample response file to be used when committing a
* product.
*
* :LOGFILE C:\OS2\INSTALL\SERVICE.LOG
* :COMMIT
* :SYSLEVEL C:\OS2\INSTALL\SYSLEVEL.OS2
* :COMMIT
* :SYSLEVEL C:\MMOS2\INSTALL\SYSLEVEL.MPM
*
* End of sample COMMIT response file.
*
**********************************************************************
*
* This is a sample response file to be used when redirecting an
* archive of a product to another existing archive location.
* One example of this would be for using a shared network archive.
* Note that the archive directory specifies the location of an
* existing archive to which the current product is being redirected.
* In this example the arbitrary drive shows S:, which may be a LAN
* drive.
*
* :LOGFILE C:\OS2\INSTALL\SERVICE.LOG
* :REDIRECT
* :SYSLEVEL C:\OS2\INSTALL\SYSLEVEL.OS2
* :ARCHIVE S:\ARCHIVE
* :REDIRECT
* :SYSLEVEL C:\MMOS2\INSTALL\SYSLEVEL.MPM
* :ARCHIVE S:\ARCHIVEM
*
* End of sample REDIRECT response file.
*

VALE A PENA MUDAR O CACHE PARA HPFS386?

Muitos usuários estão querendo passar para o HPFS386, que propicia cache de 4096. Inicialmente, o computador parece ficar mais rápido, mas, depois, podem surgir problemas, se o usuário decidir retornar ao sistema original de cache. Isso acontece porque o HPFS386 produz um tipo de cache que faz as gravações se processarem de uma forma tal que, posteriormente, correm o risco de não poiderem ser lidas quando se volta ao cache comum. O assunto é controverso. Eu coloquei o HPFS na máquina que eu uso, tive bons resultados, mas depois decidi retornar ao sistema original e quase me dou mal; felizmente, fui salvo de um crash pelo restore do Object Desktop Professional e consertei o resto com a ajuda do Graham Integrator. E assim, mais uma vez, escapei de ter de reinstalar o Merlin (até agora ainda não fiz isso e lá se vão dois anos! Nesse meio tempo, meus amigos, reinstalei o NT 4.0 umas dez vezes e o Ruindow$95 - argh!!! - umas 30). Muitos usuários constataram que o HPFS386 dá uma turbinada na máquina. Vejamos:

Teste do Maclei
All,

Resolvi fazer os testes aqui com o HPFS386. O meu equipmento é um 586 133MHz com 24Mb de memória. Utilizei o PMMail, Navigator/2 e o DeScribe, alem de medir o tempo de boot e de shutdown. Os programas eu carregava, fechava e, depois que fazia isso com todos (na ordem acima), repetia. Por isso, 2 tempos. Vamos aos testes:

1) Com o HPFS386.INI original, ou seja, cachesize 4096, maxage 5000 e
bufferidle 500 e, sem o CACHE386.EXE sem parâmetros:

- Boot
00:01:40
- Shuntdown
00:10:83
- PMMail
1o. 00:11:02 - 2o. 00:08:83
- Navigator/2
1o. 00:13:46 - 2o. 00:10:33
- DeScribe
1o. 00:11:74 - 2o. 00:09:46

2) Com o HPFS386.INI com as seguintes definições: cachesize 4096, maxage 7500 e bufferidle 60000 e, o CACHE386.EXE sem parâmetros.

- Boot
00:01:40
- Shuntdown
00:11:08
- PMMail
1o. 00:09:47 - 2o. 00:08:30
- Navigator/2
1o. 00:17:48 - 2o. 00:10:12
- DeScribe
1o. 00:10:40 - 2o. 00:09:35

3) Com o HPFS386.INI com as seguintes definições: cachesize 4096, maxage 7500 e bufferidle 60000 e, o CACHE386.EXE com os seguintes parâmetros: maxage 7500, diskidle 60000 e bufferidle 60000.

- Boot
00:01:47
- Shuntdown
00:16:90
- PMMail
1o. 00:12:46 - 2o. 00:10:80
- Navigator/2
1o. 00:15:16 - 2o. 00:10:85
- DeScribe
1o. 00:11:80 - 2o. 00:10:67

Analisando o meu teste, podem ver que o 2o. teste foi o que obteve melhor performance, mais notavel na 2a. carga dos programas, que é o que mais importa, pois o cache vai atuar justamente nisso, ou seja, repassar com mais rapidez os dados já lidos.

Se alguem puder fazer um teste semelhante e, mandar para a lista para analisarmos seria de grande ajuda.
-------------------------------------------------------------------
maclei@iname.com
maclei@geocities.com
http://www.terravista.ciclone.com.br/Ipanema/1148
-------------------------------------------------------------------