Problemas com placa Nvidia

[Eduardo Bearzoti]

Olá a todos. Estou tendo muita dificuldade em fazer funcionar o ambiente 
gráfico com o Debian Squeeze, instalado do zero em meu PC. Alguns dados 
de meu hardware são:

Placa mãe: ASUS  M2N-MX SE PLUS
Processador: AMD Athlon 64 X2 5600+  2900 MHz

Placa de video (Saída do lspci): 
nvidia Corporation G86[GeForce 8400 GS] (rev a1)

O kernel que usei foi o 2.6.32-5-amd64.

Na primeira instalação, travou tudo ao iniciar o gdm3. Suspeitando ser 
um problema com a configuração referente à placa de vídeo, encontrei na 
internet este detalhado wiki:

http://wiki.debian.org/NvidiaGraphicsDrivers

para instalação e configuração de drivers para placas Nvidia. Seguindo à 
risca suas instruções, tentei primeiro instalar o driver aberto noveau, 
mas o problema continuou. Então, segui as instruções para instalação do 
driver não-livre da Nvidia (mas disponibilizado na seção non-free do 
Squeeze), perfazendo os seguintes passos:

1) instalação do kernel module. Para tal, instalei os pacotes Debian 
module-assistant e nvidia-kernel-common. Em seguida:

m-a auto-install nvidia-kernel-source

e a instalação ocorreu sem problemas. 

2) Instalação do driver X e bibliotecas user-space. Para tal, instalei o 
pacote Debian nvidia-glx. Importante ressaltar que chequei que as 
versões dos pacotes batiam (195.36.31)

3) Configuração do X. Para tal, dei o comando:

Xorg -configure

e a partir do arquivo gerado xorg.conf.new, fiz as devidas alterações, 
comentando as linhas da Section Module em que aparece "dri", e 
alterando o Driver na Section Device para "nvidia":

Section "Module"
Load  "extmod"
#   Load  "dri"
Load  "dbe"
#   Load  "dri2"
Load  "glx"
Load  "record"
EndSection

Section "Device"
Identifier  "Card0"
Driver  "nvidia"
VendorName  "NVIDIA Corporation"
BoardName   "G86 [GeForce 8400 GS]"
BusID   "PCI:2:0:0"
EndSection

Em seguida, salvei este arquivo alterado como /etc/X11/xorg.conf. Dando 
um re-boot, pude perceber que o driver nvidia foi carregado 
corretamente. Na saída do lsmod, há:

ModuleSize Used by
nvidia10670090  24

Além disso, no arquivo log /var/log/Xorg.0.log, não há mensagens de erro 
(as linhas referentes a NVIDIA estão listadas abaixo).

Consigo acessar os terminais de console, e o login do gdm3 aparece no 
terminal 7. Porém, ao tentar logar, tudo congela e o sistema todo trava. 
Li todo o README.txt que acompanha o pacote nvidia-glx e não encontrei 
nada que pudesse me clarear o que está havendo. Nem o arquivo 
/var/log/Xorg.0.log ajuda, pois ele é criado ao se iniciar o gdm3, antes 
do problema.

Assim, não sei mais o que fazer. Toda ajuda será muito apreciada :). Não 
sei se é de algum auxílio, mas abaixo estão as linhas do Xorg.0.log 
referentes a NVIDIA. Grande abraço a todos.


(II) LoadModule: "glx"
(II) Loading /usr/lib/xorg/modules/extensions/libglx.so
(II) Module glx: vendor="NVIDIA Corporation"
compiled for 4.0.2, module version = 1.0.0
Module class: X.Org Server Extension
(II) NVIDIA GLX Module  195.36.31  Thu Jun  3 08:59:25 PDT 2010
(II) Loading extension GLX

(II) LoadModule: "nvidia"
(II) Loading /usr/lib/xorg/modules/drivers/nvidia_drv.so
(II) Module nvidia: vendor="NVIDIA Corporation"
compiled for 4.0.2, module version = 1.0.0
Module class: X.Org Video Driver
(II) NVIDIA dlloader X Driver  195.36.31  Thu Jun  3 08:27:29 PDT 2010
(II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
(II) Primary Device is: PCI 02@00:00:0

(**) Apr 13 00:46:42 NVIDIA(0): Enabling RENDER acceleration
(II) Apr 13 00:46:42 NVIDIA(0): Support for GLX with the Damage and Composite X 
extensions is
(II) Apr 13 00:46:42 NVIDIA(0): enabled.
(II) Apr 13 00:46:43 NVIDIA(0): NVIDIA GPU GeForce 8400 GS (G86) at PCI:2:0:0 
(GPU-0)
(--) Apr 13 00:46:43 NVIDIA(0): Memory: 524288 kBytes
(--) Apr 13 00:46:43 NVIDIA(0): VideoBIOS: 60.86.4a.00.23
(II) Apr 13 00:46:43 NVIDIA(0): Detected PCI Express Link width: 16X
(--) Apr 13 00:46:43 NVIDIA(0): Interlaced video modes are supported on this GPU
(--) Apr 13 00:46:43 NVIDIA(0): Connected display device(s) on GeForce 8400 GS 
at PCI:2:0:0:
(--) Apr 13 00:46:43 NVIDIA(0): LG 710E (CRT-0)
(--) Apr 13 00:46:43 NVIDIA(0): LG 710E (CRT-0): 400.0 MHz maximum pixel clock
(II) Apr 13 00:46:43 NVIDIA(0): Assigned Display Device: CRT-0
(==) Apr 13 00:46:43 NVIDIA(0): 
(==) Apr 13 00:46:43 NVIDIA(0): No modes were requested; the default mode 
"nvidia-auto-select"
(==) Apr 13 00:46:43 NVIDIA(0): will be used as the requested mode.
(==) Apr 13 00:46:43 NVIDIA(0): 
(II) Apr 13 00:46:43 NVIDIA(0): Validated modes:
(II) Apr 13 00:46:43 NVIDIA(0): "nvidia-auto-select"
(II) Apr 13 00:46:43 NVIDIA(0): Virtual screen size determined to be 1024 x 768
(--) Apr 13 00:46:43 NVIDIA(0): DPI set to (78, 78); computed from "UseEdidDpi" 
X config
(--) Apr 13 00:46:43 NVIDIA(0): option
(==) Apr 13 00:46:43 NVIDIA(0): Enabling 32-bit ARGB GLX v

Re: Qual sistema de arquivos usar?

[Iuri Guilherme dos Santos Martins]

Estabilidade é ext3.

Ext4 se tu tiver certeza que não vai ter nenhum problema com 
compatibilidade (sistemas legados ou transferência de arquivo para 
sistemas NT).


Se não tem nenhum Windows na tua máquina ou outros sistemas sem suporte 
a extents e journaling, ou se tu for instalar só um Linux no disco então 
é ext4.


Em qualquer outro cenário estabilidade só com ext3.

Em todo caso tu pode usar ext3 ou até ext2 na partição /boot.


--
To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f8772a2.7060...@gmail.com

Re: Qual sistema de arquivos usar?

[Felipe Falce]

Aqui http://www.phoronix.com/scan.php?page=article&item=linux_2634_fs&num=1tem
um benchmark bem interessante dos sistemas de arquivo mais comuns
(ext3, ext4, btrfs, xfs) e já ajuda a dar uma base.

Tenho usado ext4 mas já estou me animando com btrfs. Promete.

Vale a leitura.

May the force be with you,

*FELIPE D. FALCE*
--
[image: 2D barcode - encoded with contact information]E-mail:
fel...@linuxjf.org
Blog: www.cowabunga.com.br
Chat:[image: Google Talk:] fel...@linuxjf.org [image: Skype:] lipefalce
Find me on: [image: LinkedIn:
http://br.linkedin.com/in/felipefalce]
 [image: Twitter: http://www.twitter.com/ffalce]
 [image: Blog RSS:
http://www.cowabunga.com.br/?feed=rss2]

"To infinity... And beyond!" - Buzz Lightyear
Sumaré, SP
Brasil



Em 12 de abril de 2012 17:24, Kleber Fortaleza
escreveu:

> Em qui 12 abr 2012, às 17:00:56, Listeiro 037 escreveu:
> > Aproveitando que tocaram no assunto, queria saber qual sistema de
> > arquivos está sendo mais usado atualmente e qual é mais recomendado.
> >
> > O Reiser 3 já estava popular e o Reiser 4 era uma grande promessa, até
> > o louco do Reiser dar "kill -s 9" na esposa. Com ele fora, quem não
> > antipatizou achou outra alternativa.
> >
> > Falou-se qualquer coisa de o btrfs ter um tipo de lobby, tal como a
> > preferência dos pacotes .rpm aos .deb por causa daquela empresa lá.
> > Tanto que parece ter ganho força na árvore do kernel.
> >
> > A vantagem do ext3 era a tradição e o faro de se poder usar como ext2
> > numa eventualidade, mais aqueles atributos malucos tipo o que faz um
> > arquivo funcionar só como append, tipo um log eterno que nem o root
> > apaga se não mudar o atributo e SE o programa de mudar atributo não
> > estiver instalado.
> >
> > Não conheço ext4, Reiser 4, btrfs. XFS na única vez que usei foi PT.
> >
> > Estas são as parcas e porcas informações das quais disponho e de que me
> > lembro. Há alguma sugestão, acréscimo ou correção? Quem teve mais
> > experiẽncias testando? Não posso tanto me dar ao luxo de experimentar
> > prá não ficar reinstalando 2 vezes. Preciso de estabilidade.
> >
> > Desde já agradeço.
>
> no meu notebook estou usando ext4 em uma lvm criptografada com debian sid.
> até
> agora o ext4 não me decepcionou, portanto, recomendo.
>

Re: Qual sistema de arquivos usar?

[Kleber Fortaleza]

Em qui 12 abr 2012, às 17:00:56, Listeiro 037 escreveu:
> Aproveitando que tocaram no assunto, queria saber qual sistema de
> arquivos está sendo mais usado atualmente e qual é mais recomendado.
> 
> O Reiser 3 já estava popular e o Reiser 4 era uma grande promessa, até
> o louco do Reiser dar "kill -s 9" na esposa. Com ele fora, quem não
> antipatizou achou outra alternativa.
> 
> Falou-se qualquer coisa de o btrfs ter um tipo de lobby, tal como a
> preferência dos pacotes .rpm aos .deb por causa daquela empresa lá.
> Tanto que parece ter ganho força na árvore do kernel.
> 
> A vantagem do ext3 era a tradição e o faro de se poder usar como ext2
> numa eventualidade, mais aqueles atributos malucos tipo o que faz um
> arquivo funcionar só como append, tipo um log eterno que nem o root
> apaga se não mudar o atributo e SE o programa de mudar atributo não
> estiver instalado.
> 
> Não conheço ext4, Reiser 4, btrfs. XFS na única vez que usei foi PT.
> 
> Estas são as parcas e porcas informações das quais disponho e de que me
> lembro. Há alguma sugestão, acréscimo ou correção? Quem teve mais
> experiẽncias testando? Não posso tanto me dar ao luxo de experimentar
> prá não ficar reinstalando 2 vezes. Preciso de estabilidade.
> 
> Desde já agradeço.

no meu notebook estou usando ext4 em uma lvm criptografada com debian sid. até 
agora o ext4 não me decepcionou, portanto, recomendo.


signature.asc
Description: This is a digitally signed message part.

Re: Qual sistema de arquivos usar?

[Samir Patrice]

Essa é uma dúvida que tenho também, sobre qual melhor sistema de arquivos e
que situações um pode se sair melhor que outro.

Em 12 de abril de 2012 17:00, Listeiro 037 escreveu:

> Aproveitando que tocaram no assunto, queria saber qual sistema de
> arquivos está sendo mais usado atualmente e qual é mais recomendado.
>
> O Reiser 3 já estava popular e o Reiser 4 era uma grande promessa, até
> o louco do Reiser dar "kill -s 9" na esposa. Com ele fora, quem não
> antipatizou achou outra alternativa.
>
> Falou-se qualquer coisa de o btrfs ter um tipo de lobby, tal como a
> preferência dos pacotes .rpm aos .deb por causa daquela empresa lá.
> Tanto que parece ter ganho força na árvore do kernel.
>
> A vantagem do ext3 era a tradição e o faro de se poder usar como ext2
> numa eventualidade, mais aqueles atributos malucos tipo o que faz um
> arquivo funcionar só como append, tipo um log eterno que nem o root
> apaga se não mudar o atributo e SE o programa de mudar atributo não
> estiver instalado.
>
> Não conheço ext4, Reiser 4, btrfs. XFS na única vez que usei foi PT.
>
> Estas são as parcas e porcas informações das quais disponho e de que me
> lembro. Há alguma sugestão, acréscimo ou correção? Quem teve mais
> experiẽncias testando? Não posso tanto me dar ao luxo de experimentar
> prá não ficar reinstalando 2 vezes. Preciso de estabilidade.
>
> Desde já agradeço.
>
>
> --
> To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/20120412170056.44791...@yahoo.com.br
>
>


-- 
Samir Patrice
Técnologo em Rede

Re: Partição ReiserFS

[Gustavo Soares [SLot]]

Também fiquei uso ReiserFS nos meus servidores antigos, mas ainda acho 
que o lance do Reiser ter colocado a mulher na mala atraiu a ira do povo 
do SL k





Em 12-04-2012 17:03, Samir Patrice escreveu:
Valeu galera, vou seguir as orientações de vocês e depois posto os 
resultados.


Em 12 de abril de 2012 16:49, Fábio Rabelo > escreveu:


Boa tarde ...

O Sr. terá que efetuar um boot com um Livecd ( eu uso o Lubuntu,
rápido e funcional ) e executar os comandos do fsck :

fsck.reiserfs /dev/sda2

Ou seja lá qual for a sua partição com problemas

Ele lhe perguntará o que fazer, mande apenas checar e veja o
resultado .

Se necessário, faça as correçoões :

fsck.reiserfs --fix-fixable /dev/sda2

Se não for o suficiente, então faça o "trabalho completo" :

fsck.reiserfs --rebuild-sb /dev/sda2

fsck.reiserfs --rebuild-tree /dev/sda2

fsck.reiserfs --fix-fixable /dev/sda2

Eu nunca perdí um único arquivo em sistemas de arquivo Reiser, e
fiquei muito p#@% da vida qdo ele foi removido do suporte
principal do Debian, pois ele é mais rápido e nais fácil de
recuperar que qualquer dos EXT da vida !!!

Mas eu tb checaria o estado do HD com o smartmontools, pois
absolutamente TODAS as vezes em que eu tive que realizar este tipo
de correção de erros em um HD, este HD estava para "abrir o bico" ...


Fábio Rabelo

Em 12 de abril de 2012 16:24, Samir Patrice
mailto:samir.patr...@gmail.com>> escreveu:

Boa tarde galera,

Eu tenho um server que começou a dar problemas quando tento
copiar ou compactar uma pasta que está /var, ao tentar
compactar com o comando tar ele começa mas logo em seguida
para com um erro
/tar: Error exit delayed from previous errors./
De cara vi que podia ser um problema de HD e dei um comando
dmesg pra ver e encontrei estas msgs:
/[1593134.42] ReiserFS: warning: is_leaf: free space seems
wrong: level=1, nr_items=39, free_space=4 rdkey/
/[1593134.44] ReiserFS: sda1: warning: vs-5150:
search_by_key: invalid format found in block 5439499. Fsck?/
/[1593134.47] ReiserFS: sda1: warning: vs-13070:
reiserfs_read_locked_inode: i/o failure occurred trying to
find stat data of [17809 53388 0x0
 SD]/

Aí eu pergunto pra galera mais experiente, se eu rodar o
fsck.reiserfs /dev/sda1 eu corro o risco de apagar arquivos?
Como faço só pra checar sem corrigir?
Tentei rodar o comando e pede pra montar a partição como Read
Only, mas essa é a minha partição raiz. Como procedo nesse caso?

-- 
Samir Patrice






--
Samir Patrice
Técnologo em Rede



--
---
SLot
Linux User: 124842
XMPP: s...@jabber-br.org | slot...@gmail.com

Re: Partição ReiserFS

[Samir Patrice]

Valeu galera, vou seguir as orientações de vocês e depois posto os
resultados.

Em 12 de abril de 2012 16:49, Fábio Rabelo escreveu:

> Boa tarde ...
>
> O Sr. terá que efetuar um boot com um Livecd ( eu uso o Lubuntu, rápido e
> funcional ) e executar os comandos do fsck :
>
> fsck.reiserfs /dev/sda2
>
> Ou seja lá qual for a sua partição com problemas
>
> Ele lhe perguntará o que fazer, mande apenas checar e veja o resultado .
>
> Se necessário, faça as correçoões :
>
> fsck.reiserfs --fix-fixable /dev/sda2
>
> Se não for o suficiente, então faça o "trabalho completo" :
>
> fsck.reiserfs --rebuild-sb /dev/sda2
>
> fsck.reiserfs --rebuild-tree /dev/sda2
>
> fsck.reiserfs --fix-fixable /dev/sda2
>
> Eu nunca perdí um único arquivo em sistemas de arquivo Reiser, e fiquei
> muito p#@% da vida qdo ele foi removido do suporte principal do Debian,
> pois ele é mais rápido e nais fácil de recuperar que qualquer dos EXT da
> vida !!!
>
> Mas eu tb checaria o estado do HD com o smartmontools, pois absolutamente
> TODAS as vezes em que eu tive que realizar este tipo de correção de erros
> em um HD, este HD estava para "abrir o bico" ...
>
>
> Fábio Rabelo
>
> Em 12 de abril de 2012 16:24, Samir Patrice escreveu:
>
> Boa tarde galera,
>>
>> Eu tenho um server que começou a dar problemas quando tento copiar ou
>> compactar uma pasta que está /var, ao tentar compactar com o comando tar
>> ele começa mas logo em seguida para com um erro
>> *tar: Error exit delayed from previous errors.*
>> De cara vi que podia ser um problema de HD e dei um comando dmesg pra ver
>> e encontrei estas msgs:
>> *[1593134.42] ReiserFS: warning: is_leaf: free space seems wrong:
>> level=1, nr_items=39, free_space=4 rdkey*
>> *[1593134.44] ReiserFS: sda1: warning: vs-5150: search_by_key:
>> invalid format found in block 5439499. Fsck?*
>> *[1593134.47] ReiserFS: sda1: warning: vs-13070:
>> reiserfs_read_locked_inode: i/o failure occurred trying to find stat data
>> of [17809 53388 0x0 SD]*
>>
>> Aí eu pergunto pra galera mais experiente, se eu rodar o fsck.reiserfs
>> /dev/sda1 eu corro o risco de apagar arquivos?
>> Como faço só pra checar sem corrigir?
>> Tentei rodar o comando e pede pra montar a partição como Read Only, mas
>> essa é a minha partição raiz. Como procedo nesse caso?
>>
>> --
>> Samir Patrice
>>
>>
>


-- 
Samir Patrice
Técnologo em Rede

Re: Partição ReiserFS

[Fábio Rabelo]

Boa tarde ...

O Sr. terá que efetuar um boot com um Livecd ( eu uso o Lubuntu, rápido e
funcional ) e executar os comandos do fsck :

fsck.reiserfs /dev/sda2

Ou seja lá qual for a sua partição com problemas

Ele lhe perguntará o que fazer, mande apenas checar e veja o resultado .

Se necessário, faça as correçoões :

fsck.reiserfs --fix-fixable /dev/sda2

Se não for o suficiente, então faça o "trabalho completo" :

fsck.reiserfs --rebuild-sb /dev/sda2

fsck.reiserfs --rebuild-tree /dev/sda2

fsck.reiserfs --fix-fixable /dev/sda2

Eu nunca perdí um único arquivo em sistemas de arquivo Reiser, e fiquei
muito p#@% da vida qdo ele foi removido do suporte principal do Debian,
pois ele é mais rápido e nais fácil de recuperar que qualquer dos EXT da
vida !!!

Mas eu tb checaria o estado do HD com o smartmontools, pois absolutamente
TODAS as vezes em que eu tive que realizar este tipo de correção de erros
em um HD, este HD estava para "abrir o bico" ...


Fábio Rabelo

Em 12 de abril de 2012 16:24, Samir Patrice escreveu:

> Boa tarde galera,
>
> Eu tenho um server que começou a dar problemas quando tento copiar ou
> compactar uma pasta que está /var, ao tentar compactar com o comando tar
> ele começa mas logo em seguida para com um erro
> *tar: Error exit delayed from previous errors.*
> De cara vi que podia ser um problema de HD e dei um comando dmesg pra ver
> e encontrei estas msgs:
> *[1593134.42] ReiserFS: warning: is_leaf: free space seems wrong:
> level=1, nr_items=39, free_space=4 rdkey*
> *[1593134.44] ReiserFS: sda1: warning: vs-5150: search_by_key:
> invalid format found in block 5439499. Fsck?*
> *[1593134.47] ReiserFS: sda1: warning: vs-13070:
> reiserfs_read_locked_inode: i/o failure occurred trying to find stat data
> of [17809 53388 0x0 SD]*
>
> Aí eu pergunto pra galera mais experiente, se eu rodar o fsck.reiserfs
> /dev/sda1 eu corro o risco de apagar arquivos?
> Como faço só pra checar sem corrigir?
> Tentei rodar o comando e pede pra montar a partição como Read Only, mas
> essa é a minha partição raiz. Como procedo nesse caso?
>
> --
> Samir Patrice
>
>

Re: Partição ReiserFS

[Alcione Ferreira]

Desculpe não vi a ultima pergunta, o que vc pode fazer é rodar em um livecd.

Em 12 de abril de 2012 15:24, Samir Patrice escreveu:

> Boa tarde galera,
>
> Eu tenho um server que começou a dar problemas quando tento copiar ou
> compactar uma pasta que está /var, ao tentar compactar com o comando tar
> ele começa mas logo em seguida para com um erro
> *tar: Error exit delayed from previous errors.*
> De cara vi que podia ser um problema de HD e dei um comando dmesg pra ver
> e encontrei estas msgs:
> *[1593134.42] ReiserFS: warning: is_leaf: free space seems wrong:
> level=1, nr_items=39, free_space=4 rdkey*
> *[1593134.44] ReiserFS: sda1: warning: vs-5150: search_by_key:
> invalid format found in block 5439499. Fsck?*
> *[1593134.47] ReiserFS: sda1: warning: vs-13070:
> reiserfs_read_locked_inode: i/o failure occurred trying to find stat data
> of [17809 53388 0x0 SD]*
>
> Aí eu pergunto pra galera mais experiente, se eu rodar o fsck.reiserfs
> /dev/sda1 eu corro o risco de apagar arquivos?
> Como faço só pra checar sem corrigir?
> Tentei rodar o comando e pede pra montar a partição como Read Only, mas
> essa é a minha partição raiz. Como procedo nesse caso?
>
> --
> Samir Patrice
>
>


-- 
Alcione Ferreira
Sombra®
101080
[http://www.alcionesytes.net/]
---
Liberdade e conhecimento ao alcance de todos.

Office Escritório - http://www.openoffice.org.br/
Navegador Firefox - http://www.mozilla.org.br/
Email Thunderbird - http://www.mozilla.org.br/
---
Linux user number 432030 of http://counter.li.org/
---
ICQ: 377035698
Jabber: ksomb...@jabber.org
MSN: alcione.som...@hotmail.com
---
Curriculum: http://lattes.cnpq.br/0545256741852110

Re: Partição ReiserFS

[Alcione Ferreira]

Nas opções do fsck existe a possibilidade de checar apenas sem corrigir,
veja no manual 'man fsck.reiserfs' ou 'fsck.reiserfs --help'

Falowse

Em 12 de abril de 2012 15:24, Samir Patrice escreveu:

> Boa tarde galera,
>
> Eu tenho um server que começou a dar problemas quando tento copiar ou
> compactar uma pasta que está /var, ao tentar compactar com o comando tar
> ele começa mas logo em seguida para com um erro
> *tar: Error exit delayed from previous errors.*
> De cara vi que podia ser um problema de HD e dei um comando dmesg pra ver
> e encontrei estas msgs:
> *[1593134.42] ReiserFS: warning: is_leaf: free space seems wrong:
> level=1, nr_items=39, free_space=4 rdkey*
> *[1593134.44] ReiserFS: sda1: warning: vs-5150: search_by_key:
> invalid format found in block 5439499. Fsck?*
> *[1593134.47] ReiserFS: sda1: warning: vs-13070:
> reiserfs_read_locked_inode: i/o failure occurred trying to find stat data
> of [17809 53388 0x0 SD]*
>
> Aí eu pergunto pra galera mais experiente, se eu rodar o fsck.reiserfs
> /dev/sda1 eu corro o risco de apagar arquivos?
> Como faço só pra checar sem corrigir?
> Tentei rodar o comando e pede pra montar a partição como Read Only, mas
> essa é a minha partição raiz. Como procedo nesse caso?
>
> --
> Samir Patrice
>
>


-- 
Alcione Ferreira
Sombra®
101080
[http://www.alcionesytes.net/]
---
Liberdade e conhecimento ao alcance de todos.

Office Escritório - http://www.openoffice.org.br/
Navegador Firefox - http://www.mozilla.org.br/
Email Thunderbird - http://www.mozilla.org.br/
---
Linux user number 432030 of http://counter.li.org/
---
ICQ: 377035698
Jabber: ksomb...@jabber.org
MSN: alcione.som...@hotmail.com
---
Curriculum: http://lattes.cnpq.br/0545256741852110

Partição ReiserFS

[Samir Patrice]

Boa tarde galera,

Eu tenho um server que começou a dar problemas quando tento copiar ou
compactar uma pasta que está /var, ao tentar compactar com o comando tar
ele começa mas logo em seguida para com um erro
*tar: Error exit delayed from previous errors.*
De cara vi que podia ser um problema de HD e dei um comando dmesg pra ver e
encontrei estas msgs:
*[1593134.42] ReiserFS: warning: is_leaf: free space seems wrong:
level=1, nr_items=39, free_space=4 rdkey*
*[1593134.44] ReiserFS: sda1: warning: vs-5150: search_by_key: invalid
format found in block 5439499. Fsck?*
*[1593134.47] ReiserFS: sda1: warning: vs-13070:
reiserfs_read_locked_inode: i/o failure occurred trying to find stat data
of [17809 53388 0x0 SD]*

Aí eu pergunto pra galera mais experiente, se eu rodar o fsck.reiserfs
/dev/sda1 eu corro o risco de apagar arquivos?
Como faço só pra checar sem corrigir?
Tentei rodar o comando e pede pra montar a partição como Read Only, mas
essa é a minha partição raiz. Como procedo nesse caso?

-- 
Samir Patrice

Re: Cobol

[Dane]

Para acrescentar os testes que fiz.

Desabilitei todos os cores, exceto o core0 para testar, e ocorreu a mesma
coisa.

Complicado hehe.

Valeu pessoal

Em 12 de abril de 2012 15:56, Dane  escreveu:

> Irei dar essa essa sugestão para o pessoal do desenvolvimento.
>
> Valeu.
> Em 12 de abril de 2012 15:46, Listeiro 037 
> escreveu:
>
> Você conseguiria algum programa prá rodar ele passo a passo com
>> breakpoints?
>>
>>
>>
>> Em Thu, 12 Apr 2012 14:50:35 -0300
>> Dane  escreveu:
>>
>> > Pois é Leandro, ele no hw antigo mono-core demora 10minutos , no novo
>> > 4-cores 60 minutos.
>> >
>> > E  toda diferença está no uso do processador, enquanto o hw antigo
>> > usa todo processador disponível, o novo usa apenas 1% de um core
>> > conforme passei antes.
>> >
>> > Leandro vc está correto, pois em outros processos, ele usa a cpu
>> > normalmente, é apenas esse executável que está apresentando isto.
>> >
>> >
>> > Em 12 de abril de 2012 14:45, Leandro Henrique Stein <
>> > leandro.h.st...@gmail.com> escreveu:
>> >
>> > > Tenho outro ponto para levantar.
>> > >
>> > > O tempo de execução é realmente menor na infra de 64bits???
>> > >
>> > > Pode ser que a diferença de processamento entre o hardware de 32
>> > > bits e 64 bits leve o programa
>> > > a rodar no mesmo ritmo sem sobre carregar o hardware de 64bits.
>> > >
>> > > Concordo que a reescrita, ou pelo menos, a recompilação do software
>> > > para uma versão mais
>> > > recente em 64 bits melhoria o desempenho, mas não faz sentido dizer
>> > > que a evolução do hardware,
>> > > mesmo com um programa escrito em Cobol, com anos de uso
>> > > representaria uma queda drástica no
>> > > desempenho.
>> > >
>> > > Se isso fosse verdade todo os programas teriam de ser reescritos
>> > > para cada atualização de hardware.
>> > >
>> > > O que não é verdade.
>> > >
>> > > Leandro Henrique Stein
>> > > Analista de Informática
>> > > Claro: (41) 9935-9960
>> > > Tim: (41) 9802-9109
>> > > Skype: leandro.h.stein
>> > > Twitter: @leandrohstein
>> > >
>> > > "Desculpar-se é um sinal de fraqueza. Exceto entre amigos" - Leroy
>> > > Jethro Gibbs
>> > >
>> > >
>> > >
>> > > Em 12 de abril de 2012 13:32, Dane 
>> > > escreveu:
>> > >
>> > > Perfeito Fabio.
>> > >>
>> > >> Mas é que eu tenho a mesma estrutura em uma máquina física 32 bits
>> > >> e lá a aplicação roda perfeitamente.
>> > >>
>> > >> Em 12 de abril de 2012 13:24, Fábio Rabelo
>> > >> escreveu:
>> > >>
>> > >> Apenas uma sujestão :
>> > >>>
>> > >>> Se este seu novo hardware de 64 bits tiver memória suficiente, o
>> > >>> Sr. poderia instalar o KVM+Libvirt e instalar uma VM de 32 bits,
>> > >>> com 4 GB de RAM, 4 CPUs virtuais e ver como a sua aplicação Cobol
>> > >>> se comporta dentro desta VM .
>> > >>>
>> > >>>
>> > >>> Fábio Rabelo
>> > >>>
>> > >>>
>> > >>>
>> > >>> Em 12 de abril de 2012 13:04, Dane Brand
>> > >>> escreveu:
>> > >>>
>> > >>> De novo concordo com o P.j, com vc, com o Iuri
>> > 
>> >  Com o debian podemos rodar aplicação rodando
>> >  Com as libs 32
>> > 
>> >  Já fiz isso tbm.
>> > 
>> >  Concordo que a grande chance do problema estar
>> >  No código!
>> > 
>> >  O que eu estava tentando aqui era achar uma solução
>> >  Via SO, como o lance das libs que citei acima.
>> > 
>> > 
>> > 
>> >  Dane Brand
>> > 
>> >  Em 12/04/2012, às 11:16, "Gustavo Soares [SLot]"
>> >   escreveu:
>> > 
>> >   Amigo, é exatamente que o P.J está tentando te falar.  O seu
>> >  sistema não irá funcionar como você quer, simplesmente fazendo
>> >  upgrade do hardware, o lance aí é mais embaixo, é no cobol.
>> > 
>> >  Creio que você não terá muito o que fazer no linux ou no
>> >  hardware.
>> > 
>> > 
>> > 
>> >  Em 12-04-2012 11:03, Dane escreveu:
>> > 
>> >  Pessoal, eu não sou desenvolvedor, sou da Infra.
>> > 
>> >  Mas vejam, eu não quero aumentar o desempenho, não quero usar
>> >  threads, gostaria de algum todas as aplicações estão rodando
>> >  normalmente.
>> > 
>> >  Só gostaria se alguém souber me afirmar o pq um processo está
>> >  usando 1% da cpu, quais podem ser os motivos para isto.
>> > 
>> >  Obrigado.
>> > 
>> >  Em 12-04-2012 10:39, Rodolfo escreveu:
>> > 
>> >  Quais aplicações ? Tem como listar ?
>> > 
>> >  E porque não migram pra Java ?
>> > 
>> > 
>> >  E como falaram ali em cima, você aparentemente usava uma
>> >  aplicação desenvolvida pra rodar em 32 bits, logo, quando usa em
>> >  64 bits, o funcionamente não será o mesmo, precisa recompilar o
>> >  mesmo para 64 bits.
>> > 
>> > 
>> >  Abraços.
>> > 
>> >   Em 12 de abril de 2012 09:29, Dane  escreveu:
>> > 
>> > > Não ficou muito claro, pelo seguinte, eu só tenho problema em
>> > > algumas aplicações e qual a referência disto com o uso do
>> > > processador?
>> > >
>> > > Em 12-04-2012 10:

Re: Cobol

[Dane]

Irei dar essa essa sugestão para o pessoal do desenvolvimento.

Valeu.
Em 12 de abril de 2012 15:46, Listeiro 037 escreveu:

> Você conseguiria algum programa prá rodar ele passo a passo com
> breakpoints?
>
>
>
> Em Thu, 12 Apr 2012 14:50:35 -0300
> Dane  escreveu:
>
> > Pois é Leandro, ele no hw antigo mono-core demora 10minutos , no novo
> > 4-cores 60 minutos.
> >
> > E  toda diferença está no uso do processador, enquanto o hw antigo
> > usa todo processador disponível, o novo usa apenas 1% de um core
> > conforme passei antes.
> >
> > Leandro vc está correto, pois em outros processos, ele usa a cpu
> > normalmente, é apenas esse executável que está apresentando isto.
> >
> >
> > Em 12 de abril de 2012 14:45, Leandro Henrique Stein <
> > leandro.h.st...@gmail.com> escreveu:
> >
> > > Tenho outro ponto para levantar.
> > >
> > > O tempo de execução é realmente menor na infra de 64bits???
> > >
> > > Pode ser que a diferença de processamento entre o hardware de 32
> > > bits e 64 bits leve o programa
> > > a rodar no mesmo ritmo sem sobre carregar o hardware de 64bits.
> > >
> > > Concordo que a reescrita, ou pelo menos, a recompilação do software
> > > para uma versão mais
> > > recente em 64 bits melhoria o desempenho, mas não faz sentido dizer
> > > que a evolução do hardware,
> > > mesmo com um programa escrito em Cobol, com anos de uso
> > > representaria uma queda drástica no
> > > desempenho.
> > >
> > > Se isso fosse verdade todo os programas teriam de ser reescritos
> > > para cada atualização de hardware.
> > >
> > > O que não é verdade.
> > >
> > > Leandro Henrique Stein
> > > Analista de Informática
> > > Claro: (41) 9935-9960
> > > Tim: (41) 9802-9109
> > > Skype: leandro.h.stein
> > > Twitter: @leandrohstein
> > >
> > > "Desculpar-se é um sinal de fraqueza. Exceto entre amigos" - Leroy
> > > Jethro Gibbs
> > >
> > >
> > >
> > > Em 12 de abril de 2012 13:32, Dane 
> > > escreveu:
> > >
> > > Perfeito Fabio.
> > >>
> > >> Mas é que eu tenho a mesma estrutura em uma máquina física 32 bits
> > >> e lá a aplicação roda perfeitamente.
> > >>
> > >> Em 12 de abril de 2012 13:24, Fábio Rabelo
> > >> escreveu:
> > >>
> > >> Apenas uma sujestão :
> > >>>
> > >>> Se este seu novo hardware de 64 bits tiver memória suficiente, o
> > >>> Sr. poderia instalar o KVM+Libvirt e instalar uma VM de 32 bits,
> > >>> com 4 GB de RAM, 4 CPUs virtuais e ver como a sua aplicação Cobol
> > >>> se comporta dentro desta VM .
> > >>>
> > >>>
> > >>> Fábio Rabelo
> > >>>
> > >>>
> > >>>
> > >>> Em 12 de abril de 2012 13:04, Dane Brand
> > >>> escreveu:
> > >>>
> > >>> De novo concordo com o P.j, com vc, com o Iuri
> > 
> >  Com o debian podemos rodar aplicação rodando
> >  Com as libs 32
> > 
> >  Já fiz isso tbm.
> > 
> >  Concordo que a grande chance do problema estar
> >  No código!
> > 
> >  O que eu estava tentando aqui era achar uma solução
> >  Via SO, como o lance das libs que citei acima.
> > 
> > 
> > 
> >  Dane Brand
> > 
> >  Em 12/04/2012, às 11:16, "Gustavo Soares [SLot]"
> >   escreveu:
> > 
> >   Amigo, é exatamente que o P.J está tentando te falar.  O seu
> >  sistema não irá funcionar como você quer, simplesmente fazendo
> >  upgrade do hardware, o lance aí é mais embaixo, é no cobol.
> > 
> >  Creio que você não terá muito o que fazer no linux ou no
> >  hardware.
> > 
> > 
> > 
> >  Em 12-04-2012 11:03, Dane escreveu:
> > 
> >  Pessoal, eu não sou desenvolvedor, sou da Infra.
> > 
> >  Mas vejam, eu não quero aumentar o desempenho, não quero usar
> >  threads, gostaria de algum todas as aplicações estão rodando
> >  normalmente.
> > 
> >  Só gostaria se alguém souber me afirmar o pq um processo está
> >  usando 1% da cpu, quais podem ser os motivos para isto.
> > 
> >  Obrigado.
> > 
> >  Em 12-04-2012 10:39, Rodolfo escreveu:
> > 
> >  Quais aplicações ? Tem como listar ?
> > 
> >  E porque não migram pra Java ?
> > 
> > 
> >  E como falaram ali em cima, você aparentemente usava uma
> >  aplicação desenvolvida pra rodar em 32 bits, logo, quando usa em
> >  64 bits, o funcionamente não será o mesmo, precisa recompilar o
> >  mesmo para 64 bits.
> > 
> > 
> >  Abraços.
> > 
> >   Em 12 de abril de 2012 09:29, Dane  escreveu:
> > 
> > > Não ficou muito claro, pelo seguinte, eu só tenho problema em
> > > algumas aplicações e qual a referência disto com o uso do
> > > processador?
> > >
> > > Em 12-04-2012 10:10, Iuri Guilherme dos Santos Martins escreveu:
> > >
> > > Em 12-04-2012 09:59, Dane escreveu:
> > >>
> > >>> Olá Iuri,
> > >>>
> > >>> Você já teve algum problema parecido?
> > >>>
> > >>> Está mesmo relacionado a arquitetura?
> > >>>
> > >>
> > >> Não.
> > >>
> > >> Um programa escrito em Cobol dep

Re: Cobol

[Listeiro 037]

Você conseguiria algum programa prá rodar ele passo a passo com
breakpoints? 



Em Thu, 12 Apr 2012 14:50:35 -0300
Dane  escreveu:

> Pois é Leandro, ele no hw antigo mono-core demora 10minutos , no novo
> 4-cores 60 minutos.
> 
> E  toda diferença está no uso do processador, enquanto o hw antigo
> usa todo processador disponível, o novo usa apenas 1% de um core
> conforme passei antes.
> 
> Leandro vc está correto, pois em outros processos, ele usa a cpu
> normalmente, é apenas esse executável que está apresentando isto.
> 
> 
> Em 12 de abril de 2012 14:45, Leandro Henrique Stein <
> leandro.h.st...@gmail.com> escreveu:
> 
> > Tenho outro ponto para levantar.
> >
> > O tempo de execução é realmente menor na infra de 64bits???
> >
> > Pode ser que a diferença de processamento entre o hardware de 32
> > bits e 64 bits leve o programa
> > a rodar no mesmo ritmo sem sobre carregar o hardware de 64bits.
> >
> > Concordo que a reescrita, ou pelo menos, a recompilação do software
> > para uma versão mais
> > recente em 64 bits melhoria o desempenho, mas não faz sentido dizer
> > que a evolução do hardware,
> > mesmo com um programa escrito em Cobol, com anos de uso
> > representaria uma queda drástica no
> > desempenho.
> >
> > Se isso fosse verdade todo os programas teriam de ser reescritos
> > para cada atualização de hardware.
> >
> > O que não é verdade.
> >
> > Leandro Henrique Stein
> > Analista de Informática
> > Claro: (41) 9935-9960
> > Tim: (41) 9802-9109
> > Skype: leandro.h.stein
> > Twitter: @leandrohstein
> >
> > "Desculpar-se é um sinal de fraqueza. Exceto entre amigos" - Leroy
> > Jethro Gibbs
> >
> >
> >
> > Em 12 de abril de 2012 13:32, Dane 
> > escreveu:
> >
> > Perfeito Fabio.
> >>
> >> Mas é que eu tenho a mesma estrutura em uma máquina física 32 bits
> >> e lá a aplicação roda perfeitamente.
> >>
> >> Em 12 de abril de 2012 13:24, Fábio Rabelo
> >> escreveu:
> >>
> >> Apenas uma sujestão :
> >>>
> >>> Se este seu novo hardware de 64 bits tiver memória suficiente, o
> >>> Sr. poderia instalar o KVM+Libvirt e instalar uma VM de 32 bits,
> >>> com 4 GB de RAM, 4 CPUs virtuais e ver como a sua aplicação Cobol
> >>> se comporta dentro desta VM .
> >>>
> >>>
> >>> Fábio Rabelo
> >>>
> >>>
> >>>
> >>> Em 12 de abril de 2012 13:04, Dane Brand
> >>> escreveu:
> >>>
> >>> De novo concordo com o P.j, com vc, com o Iuri
> 
>  Com o debian podemos rodar aplicação rodando
>  Com as libs 32
> 
>  Já fiz isso tbm.
> 
>  Concordo que a grande chance do problema estar
>  No código!
> 
>  O que eu estava tentando aqui era achar uma solução
>  Via SO, como o lance das libs que citei acima.
> 
> 
> 
>  Dane Brand
> 
>  Em 12/04/2012, às 11:16, "Gustavo Soares [SLot]"
>   escreveu:
> 
>   Amigo, é exatamente que o P.J está tentando te falar.  O seu
>  sistema não irá funcionar como você quer, simplesmente fazendo
>  upgrade do hardware, o lance aí é mais embaixo, é no cobol.
> 
>  Creio que você não terá muito o que fazer no linux ou no
>  hardware.
> 
> 
> 
>  Em 12-04-2012 11:03, Dane escreveu:
> 
>  Pessoal, eu não sou desenvolvedor, sou da Infra.
> 
>  Mas vejam, eu não quero aumentar o desempenho, não quero usar
>  threads, gostaria de algum todas as aplicações estão rodando
>  normalmente.
> 
>  Só gostaria se alguém souber me afirmar o pq um processo está
>  usando 1% da cpu, quais podem ser os motivos para isto.
> 
>  Obrigado.
> 
>  Em 12-04-2012 10:39, Rodolfo escreveu:
> 
>  Quais aplicações ? Tem como listar ?
> 
>  E porque não migram pra Java ?
> 
> 
>  E como falaram ali em cima, você aparentemente usava uma
>  aplicação desenvolvida pra rodar em 32 bits, logo, quando usa em
>  64 bits, o funcionamente não será o mesmo, precisa recompilar o
>  mesmo para 64 bits.
> 
> 
>  Abraços.
> 
>   Em 12 de abril de 2012 09:29, Dane  escreveu:
> 
> > Não ficou muito claro, pelo seguinte, eu só tenho problema em
> > algumas aplicações e qual a referência disto com o uso do
> > processador?
> >
> > Em 12-04-2012 10:10, Iuri Guilherme dos Santos Martins escreveu:
> >
> > Em 12-04-2012 09:59, Dane escreveu:
> >>
> >>> Olá Iuri,
> >>>
> >>> Você já teve algum problema parecido?
> >>>
> >>> Está mesmo relacionado a arquitetura?
> >>>
> >>
> >> Não.
> >>
> >> Um programa escrito em Cobol depende da configuração da
> >> máquina. Não é Java, é Cobol.
> >>
> >> Se tu mudar o processador ou alguma outra parte do hardware sem
> >> alterar o código fonte do programa, ele vai se comportar de
> >> forma diferente.
> >>
> >> Principalmente quando tu muda de uma arquitetura de
> >> processador de 32 bits para 64 bits.
> >>
> >> Esse efeito que tu teve não é somente facilmente previsto

Re: Cobol

[Dane]

mono - 3.4GHz
core - 3.10GHz

Leandro o grande problema e que o uso do core fica em 1%, ele nem excuta
por exemplo que nem uma aplicação normal com 100% do core que ele foi
entregue, o tempo idle da cpu fica em 99% , 98%, enu

Em 12 de abril de 2012 15:21, Leandro Henrique Stein <
leandro.h.st...@gmail.com> escreveu:

> Dane,
>
> Qual são as frequências dos cores?? Tanto do mono-core quanto do
> multi-core (neste caso, de cada um dos cores).
> Se a frequência dos cores multi-core for muito menor do que a do mono-core
> a diferença no tempo de execução
> pode ser causada pelo baixo desempenho do hardware.
>
> Tive problemas uma vez com um programa win32 que não era otimizado para
> multi-core (windows XP e Vista) que
> o programa era executado SEMPRE no core 0, juntamente com o SO e os outros
> programas mono-core.
> Neste caso tive que recompilar o programa para que ele funcionasse de
> forma correta escolhendo o "melhor" core
> para execução, mas reitero que a alteração foi necessária por uma falha no
> kernel do Windows XP e Vista, usando
> o mesmo programa mono-core no Windows 7 o próprio SO redireciona o
> programa para o "melhor" core.
>
> Uma coisa boa do Linux é que ele executa o Kernel sempre no último core da
> máquina, por exemplo se tenho
> 1 core ele executa no core 0, se tenho 4 cores ele executa no core 3, com
> isso os kernel não influência nem é
> influenciado por programas mais antigos preparados para hardware mono-core.
>
> Leandro Henrique Stein
> Analista de Informática
> Claro: (41) 9935-9960
> Tim: (41) 9802-9109
> Skype: leandro.h.stein
> Twitter: @leandrohstein
>
> "Desculpar-se é um sinal de fraqueza. Exceto entre amigos" - Leroy Jethro
> Gibbs
>
>
>
> Em 12 de abril de 2012 14:50, Dane  escreveu:
>
>  Pois é Leandro, ele no hw antigo mono-core demora 10minutos , no novo
>> 4-cores 60 minutos.
>>
>> E  toda diferença está no uso do processador, enquanto o hw antigo usa
>> todo processador disponível, o novo usa apenas 1% de um core conforme
>> passei antes.
>>
>> Leandro vc está correto, pois em outros processos, ele usa a cpu
>> normalmente, é apenas esse executável que está apresentando isto.
>>
>>
>> Em 12 de abril de 2012 14:45, Leandro Henrique Stein <
>> leandro.h.st...@gmail.com> escreveu:
>>
>> Tenho outro ponto para levantar.
>>>
>>> O tempo de execução é realmente menor na infra de 64bits???
>>>
>>> Pode ser que a diferença de processamento entre o hardware de 32 bits e
>>> 64 bits leve o programa
>>> a rodar no mesmo ritmo sem sobre carregar o hardware de 64bits.
>>>
>>> Concordo que a reescrita, ou pelo menos, a recompilação do software para
>>> uma versão mais
>>> recente em 64 bits melhoria o desempenho, mas não faz sentido dizer que
>>> a evolução do hardware,
>>> mesmo com um programa escrito em Cobol, com anos de uso representaria
>>> uma queda drástica no
>>> desempenho.
>>>
>>> Se isso fosse verdade todo os programas teriam de ser reescritos para
>>> cada atualização de hardware.
>>>
>>> O que não é verdade.
>>>
>>> Leandro Henrique Stein
>>> Analista de Informática
>>> Claro: (41) 9935-9960
>>> Tim: (41) 9802-9109
>>> Skype: leandro.h.stein
>>> Twitter: @leandrohstein
>>>
>>> "Desculpar-se é um sinal de fraqueza. Exceto entre amigos" - Leroy
>>> Jethro Gibbs
>>>
>>>
>>>
>>> Em 12 de abril de 2012 13:32, Dane  escreveu:
>>>
>>> Perfeito Fabio.

 Mas é que eu tenho a mesma estrutura em uma máquina física 32 bits e lá
 a aplicação roda perfeitamente.

 Em 12 de abril de 2012 13:24, Fábio Rabelo 
 escreveu:

 Apenas uma sujestão :
>
> Se este seu novo hardware de 64 bits tiver memória suficiente, o Sr.
> poderia instalar o KVM+Libvirt e instalar uma VM de 32 bits, com 4 GB de
> RAM, 4 CPUs virtuais e ver como a sua aplicação Cobol se comporta dentro
> desta VM .
>
>
> Fábio Rabelo
>
>
>
> Em 12 de abril de 2012 13:04, Dane Brand escreveu:
>
> De novo concordo com o P.j, com vc, com o Iuri
>>
>> Com o debian podemos rodar aplicação rodando
>> Com as libs 32
>>
>> Já fiz isso tbm.
>>
>> Concordo que a grande chance do problema estar
>> No código!
>>
>> O que eu estava tentando aqui era achar uma solução
>> Via SO, como o lance das libs que citei acima.
>>
>>
>>
>> Dane Brand
>>
>> Em 12/04/2012, às 11:16, "Gustavo Soares [SLot]" 
>> escreveu:
>>
>>  Amigo, é exatamente que o P.J está tentando te falar.  O seu sistema
>> não irá funcionar como você quer, simplesmente fazendo upgrade do 
>> hardware,
>> o lance aí é mais embaixo, é no cobol.
>>
>> Creio que você não terá muito o que fazer no linux ou no hardware.
>>
>>
>>
>> Em 12-04-2012 11:03, Dane escreveu:
>>
>> Pessoal, eu não sou desenvolvedor, sou da Infra.
>>
>> Mas vejam, eu não quero aumentar o desempenho, não quero usar
>> threads, gostaria de algum todas as aplicações estão rodando normal

Re: Cobol

[Dane]

Pois é Leandro, ele no hw antigo mono-core demora 10minutos , no novo
4-cores 60 minutos.

E  toda diferença está no uso do processador, enquanto o hw antigo usa todo
processador disponível, o novo usa apenas 1% de um core conforme passei
antes.

Leandro vc está correto, pois em outros processos, ele usa a cpu
normalmente, é apenas esse executável que está apresentando isto.


Em 12 de abril de 2012 14:45, Leandro Henrique Stein <
leandro.h.st...@gmail.com> escreveu:

> Tenho outro ponto para levantar.
>
> O tempo de execução é realmente menor na infra de 64bits???
>
> Pode ser que a diferença de processamento entre o hardware de 32 bits e 64
> bits leve o programa
> a rodar no mesmo ritmo sem sobre carregar o hardware de 64bits.
>
> Concordo que a reescrita, ou pelo menos, a recompilação do software para
> uma versão mais
> recente em 64 bits melhoria o desempenho, mas não faz sentido dizer que a
> evolução do hardware,
> mesmo com um programa escrito em Cobol, com anos de uso representaria uma
> queda drástica no
> desempenho.
>
> Se isso fosse verdade todo os programas teriam de ser reescritos para cada
> atualização de hardware.
>
> O que não é verdade.
>
> Leandro Henrique Stein
> Analista de Informática
> Claro: (41) 9935-9960
> Tim: (41) 9802-9109
> Skype: leandro.h.stein
> Twitter: @leandrohstein
>
> "Desculpar-se é um sinal de fraqueza. Exceto entre amigos" - Leroy Jethro
> Gibbs
>
>
>
> Em 12 de abril de 2012 13:32, Dane  escreveu:
>
> Perfeito Fabio.
>>
>> Mas é que eu tenho a mesma estrutura em uma máquina física 32 bits e lá a
>> aplicação roda perfeitamente.
>>
>> Em 12 de abril de 2012 13:24, Fábio Rabelo 
>> escreveu:
>>
>> Apenas uma sujestão :
>>>
>>> Se este seu novo hardware de 64 bits tiver memória suficiente, o Sr.
>>> poderia instalar o KVM+Libvirt e instalar uma VM de 32 bits, com 4 GB de
>>> RAM, 4 CPUs virtuais e ver como a sua aplicação Cobol se comporta dentro
>>> desta VM .
>>>
>>>
>>> Fábio Rabelo
>>>
>>>
>>>
>>> Em 12 de abril de 2012 13:04, Dane Brand escreveu:
>>>
>>> De novo concordo com o P.j, com vc, com o Iuri

 Com o debian podemos rodar aplicação rodando
 Com as libs 32

 Já fiz isso tbm.

 Concordo que a grande chance do problema estar
 No código!

 O que eu estava tentando aqui era achar uma solução
 Via SO, como o lance das libs que citei acima.



 Dane Brand

 Em 12/04/2012, às 11:16, "Gustavo Soares [SLot]" 
 escreveu:

  Amigo, é exatamente que o P.J está tentando te falar.  O seu sistema
 não irá funcionar como você quer, simplesmente fazendo upgrade do hardware,
 o lance aí é mais embaixo, é no cobol.

 Creio que você não terá muito o que fazer no linux ou no hardware.



 Em 12-04-2012 11:03, Dane escreveu:

 Pessoal, eu não sou desenvolvedor, sou da Infra.

 Mas vejam, eu não quero aumentar o desempenho, não quero usar threads,
 gostaria de algum todas as aplicações estão rodando normalmente.

 Só gostaria se alguém souber me afirmar o pq um processo está usando 1%
 da cpu, quais podem ser os motivos para isto.

 Obrigado.

 Em 12-04-2012 10:39, Rodolfo escreveu:

 Quais aplicações ? Tem como listar ?

 E porque não migram pra Java ?


 E como falaram ali em cima, você aparentemente usava uma aplicação
 desenvolvida pra rodar em 32 bits, logo, quando usa em 64 bits, o
 funcionamente não será o mesmo, precisa recompilar o mesmo para 64 bits.


 Abraços.

  Em 12 de abril de 2012 09:29, Dane  escreveu:

> Não ficou muito claro, pelo seguinte, eu só tenho problema em algumas
> aplicações e qual a referência disto com o uso do processador?
>
> Em 12-04-2012 10:10, Iuri Guilherme dos Santos Martins escreveu:
>
> Em 12-04-2012 09:59, Dane escreveu:
>>
>>> Olá Iuri,
>>>
>>> Você já teve algum problema parecido?
>>>
>>> Está mesmo relacionado a arquitetura?
>>>
>>
>> Não.
>>
>> Um programa escrito em Cobol depende da configuração da máquina. Não
>> é Java, é Cobol.
>>
>> Se tu mudar o processador ou alguma outra parte do hardware sem
>> alterar o código fonte do programa, ele vai se comportar de forma 
>> diferente.
>>
>> Principalmente quando tu muda de uma arquitetura de processador de 32
>> bits para 64 bits.
>>
>> Esse efeito que tu teve não é somente facilmente previsto, é uma
>> certeza.
>>
>>
>>
> --
>  Att. Dane Everson
> Atua Sistemas de Informação
> Skype: dane.atua
> Msn: d...@atua.com.br
> Fone: (54) 3045-4044
> Celular: (54) 9905-5712
> Linux User #548369
>
>
>
> --
> To UNSUBSCRIBE, email to
> debian-user-portuguese-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
>  Archive: http://lists.d

Re: Cobol

[Dane]

Perfeito Fabio.

Mas é que eu tenho a mesma estrutura em uma máquina física 32 bits e lá a
aplicação roda perfeitamente.

Em 12 de abril de 2012 13:24, Fábio Rabelo escreveu:

> Apenas uma sujestão :
>
> Se este seu novo hardware de 64 bits tiver memória suficiente, o Sr.
> poderia instalar o KVM+Libvirt e instalar uma VM de 32 bits, com 4 GB de
> RAM, 4 CPUs virtuais e ver como a sua aplicação Cobol se comporta dentro
> desta VM .
>
>
> Fábio Rabelo
>
>
>
> Em 12 de abril de 2012 13:04, Dane Brand escreveu:
>
> De novo concordo com o P.j, com vc, com o Iuri
>>
>> Com o debian podemos rodar aplicação rodando
>> Com as libs 32
>>
>> Já fiz isso tbm.
>>
>> Concordo que a grande chance do problema estar
>> No código!
>>
>> O que eu estava tentando aqui era achar uma solução
>> Via SO, como o lance das libs que citei acima.
>>
>>
>>
>> Dane Brand
>>
>> Em 12/04/2012, às 11:16, "Gustavo Soares [SLot]" 
>> escreveu:
>>
>>  Amigo, é exatamente que o P.J está tentando te falar.  O seu sistema não
>> irá funcionar como você quer, simplesmente fazendo upgrade do hardware, o
>> lance aí é mais embaixo, é no cobol.
>>
>> Creio que você não terá muito o que fazer no linux ou no hardware.
>>
>>
>>
>> Em 12-04-2012 11:03, Dane escreveu:
>>
>> Pessoal, eu não sou desenvolvedor, sou da Infra.
>>
>> Mas vejam, eu não quero aumentar o desempenho, não quero usar threads,
>> gostaria de algum todas as aplicações estão rodando normalmente.
>>
>> Só gostaria se alguém souber me afirmar o pq um processo está usando 1%
>> da cpu, quais podem ser os motivos para isto.
>>
>> Obrigado.
>>
>> Em 12-04-2012 10:39, Rodolfo escreveu:
>>
>> Quais aplicações ? Tem como listar ?
>>
>> E porque não migram pra Java ?
>>
>>
>> E como falaram ali em cima, você aparentemente usava uma aplicação
>> desenvolvida pra rodar em 32 bits, logo, quando usa em 64 bits, o
>> funcionamente não será o mesmo, precisa recompilar o mesmo para 64 bits.
>>
>>
>> Abraços.
>>
>>  Em 12 de abril de 2012 09:29, Dane  escreveu:
>>
>>> Não ficou muito claro, pelo seguinte, eu só tenho problema em algumas
>>> aplicações e qual a referência disto com o uso do processador?
>>>
>>> Em 12-04-2012 10:10, Iuri Guilherme dos Santos Martins escreveu:
>>>
>>> Em 12-04-2012 09:59, Dane escreveu:

> Olá Iuri,
>
> Você já teve algum problema parecido?
>
> Está mesmo relacionado a arquitetura?
>

 Não.

 Um programa escrito em Cobol depende da configuração da máquina. Não é
 Java, é Cobol.

 Se tu mudar o processador ou alguma outra parte do hardware sem alterar
 o código fonte do programa, ele vai se comportar de forma diferente.

 Principalmente quando tu muda de uma arquitetura de processador de 32
 bits para 64 bits.

 Esse efeito que tu teve não é somente facilmente previsto, é uma
 certeza.



>>> --
>>>  Att. Dane Everson
>>> Atua Sistemas de Informação
>>> Skype: dane.atua
>>> Msn: d...@atua.com.br
>>> Fone: (54) 3045-4044
>>> Celular: (54) 9905-5712
>>> Linux User #548369
>>>
>>>
>>>
>>> --
>>> To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
>>> with a subject of "unsubscribe". Trouble? Contact
>>> listmas...@lists.debian.org
>>>  Archive: http://lists.debian.org/4f86d8b6.4040...@atua.com.br
>>>
>>>
>>
>> --
>> Att. Dane Everson
>> Atua Sistemas de Informação
>> Skype: dane.atua
>> Msn: d...@atua.com.br
>> Fone: (54) 3045-4044
>> Celular: (54) 9905-5712
>> Linux User #548369
>>
>>
>>
>> --
>> ---
>> SLot
>> Linux User: 124842
>> XMPP: s...@jabber-br.org | slot...@gmail.com
>>
>>
>

Re: Cobol

[Fábio Rabelo]

Apenas uma sujestão :

Se este seu novo hardware de 64 bits tiver memória suficiente, o Sr.
poderia instalar o KVM+Libvirt e instalar uma VM de 32 bits, com 4 GB de
RAM, 4 CPUs virtuais e ver como a sua aplicação Cobol se comporta dentro
desta VM .


Fábio Rabelo



Em 12 de abril de 2012 13:04, Dane Brand  escreveu:

> De novo concordo com o P.j, com vc, com o Iuri
>
> Com o debian podemos rodar aplicação rodando
> Com as libs 32
>
> Já fiz isso tbm.
>
> Concordo que a grande chance do problema estar
> No código!
>
> O que eu estava tentando aqui era achar uma solução
> Via SO, como o lance das libs que citei acima.
>
>
>
> Dane Brand
>
> Em 12/04/2012, às 11:16, "Gustavo Soares [SLot]" 
> escreveu:
>
> Amigo, é exatamente que o P.J está tentando te falar.  O seu sistema não
> irá funcionar como você quer, simplesmente fazendo upgrade do hardware, o
> lance aí é mais embaixo, é no cobol.
>
> Creio que você não terá muito o que fazer no linux ou no hardware.
>
>
>
> Em 12-04-2012 11:03, Dane escreveu:
>
> Pessoal, eu não sou desenvolvedor, sou da Infra.
>
> Mas vejam, eu não quero aumentar o desempenho, não quero usar threads,
> gostaria de algum todas as aplicações estão rodando normalmente.
>
> Só gostaria se alguém souber me afirmar o pq um processo está usando 1% da
> cpu, quais podem ser os motivos para isto.
>
> Obrigado.
>
> Em 12-04-2012 10:39, Rodolfo escreveu:
>
> Quais aplicações ? Tem como listar ?
>
> E porque não migram pra Java ?
>
>
> E como falaram ali em cima, você aparentemente usava uma aplicação
> desenvolvida pra rodar em 32 bits, logo, quando usa em 64 bits, o
> funcionamente não será o mesmo, precisa recompilar o mesmo para 64 bits.
>
>
> Abraços.
>
>  Em 12 de abril de 2012 09:29, Dane  escreveu:
>
>> Não ficou muito claro, pelo seguinte, eu só tenho problema em algumas
>> aplicações e qual a referência disto com o uso do processador?
>>
>> Em 12-04-2012 10:10, Iuri Guilherme dos Santos Martins escreveu:
>>
>> Em 12-04-2012 09:59, Dane escreveu:
>>>
 Olá Iuri,

 Você já teve algum problema parecido?

 Está mesmo relacionado a arquitetura?

>>>
>>> Não.
>>>
>>> Um programa escrito em Cobol depende da configuração da máquina. Não é
>>> Java, é Cobol.
>>>
>>> Se tu mudar o processador ou alguma outra parte do hardware sem alterar
>>> o código fonte do programa, ele vai se comportar de forma diferente.
>>>
>>> Principalmente quando tu muda de uma arquitetura de processador de 32
>>> bits para 64 bits.
>>>
>>> Esse efeito que tu teve não é somente facilmente previsto, é uma certeza.
>>>
>>>
>>>
>> --
>>  Att. Dane Everson
>> Atua Sistemas de Informação
>> Skype: dane.atua
>> Msn: d...@atua.com.br
>> Fone: (54) 3045-4044
>> Celular: (54) 9905-5712
>> Linux User #548369
>>
>>
>>
>> --
>> To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
>> with a subject of "unsubscribe". Trouble? Contact
>> listmas...@lists.debian.org
>>  Archive: http://lists.debian.org/4f86d8b6.4040...@atua.com.br
>>
>>
>
> --
> Att. Dane Everson
> Atua Sistemas de Informação
> Skype: dane.atua
> Msn: d...@atua.com.br
> Fone: (54) 3045-4044
> Celular: (54) 9905-5712
> Linux User #548369
>
>
>
> --
> ---
> SLot
> Linux User: 124842
> XMPP: s...@jabber-br.org | slot...@gmail.com
>
>

Re: Cobol

[Dane Brand]

De novo concordo com o P.j, com vc, com o Iuri

Com o debian podemos rodar aplicação rodando
Com as libs 32

Já fiz isso tbm. 

Concordo que a grande chance do problema estar
No código! 

O que eu estava tentando aqui era achar uma solução
Via SO, como o lance das libs que citei acima.



Dane Brand

Em 12/04/2012, às 11:16, "Gustavo Soares [SLot]"  escreveu:

> Amigo, é exatamente que o P.J está tentando te falar.  O seu sistema não irá 
> funcionar como você quer, simplesmente fazendo upgrade do hardware, o lance 
> aí é mais embaixo, é no cobol.
> 
> Creio que você não terá muito o que fazer no linux ou no hardware. 
> 
> 
> 
> Em 12-04-2012 11:03, Dane escreveu:
>> 
>> Pessoal, eu não sou desenvolvedor, sou da Infra. 
>> 
>> Mas vejam, eu não quero aumentar o desempenho, não quero usar threads, 
>> gostaria de algum todas as aplicações estão rodando normalmente. 
>> 
>> Só gostaria se alguém souber me afirmar o pq um processo está usando 1% da 
>> cpu, quais podem ser os motivos para isto. 
>> 
>> Obrigado. 
>> 
>> Em 12-04-2012 10:39, Rodolfo escreveu:
>>> 
>>> Quais aplicações ? Tem como listar ?
>>>  
>>> E porque não migram pra Java ?
>>>  
>>>  
>>> E como falaram ali em cima, você aparentemente usava uma aplicação 
>>> desenvolvida pra rodar em 32 bits, logo, quando usa em 64 bits, o 
>>> funcionamente não será o mesmo, precisa recompilar o mesmo para 64 bits.
>>>  
>>>  
>>> Abraços.
>>> 
>>> Em 12 de abril de 2012 09:29, Dane  escreveu:
>>> Não ficou muito claro, pelo seguinte, eu só tenho problema em algumas 
>>> aplicações e qual a referência disto com o uso do processador?
>>> 
>>> Em 12-04-2012 10:10, Iuri Guilherme dos Santos Martins escreveu:
>>> 
>>> Em 12-04-2012 09:59, Dane escreveu:
>>> Olá Iuri,
>>> 
>>> Você já teve algum problema parecido?
>>> 
>>> Está mesmo relacionado a arquitetura?
>>> 
>>> Não.
>>> 
>>> Um programa escrito em Cobol depende da configuração da máquina. Não é 
>>> Java, é Cobol.
>>> 
>>> Se tu mudar o processador ou alguma outra parte do hardware sem alterar o 
>>> código fonte do programa, ele vai se comportar de forma diferente.
>>> 
>>> Principalmente quando tu muda de uma arquitetura de processador de 32 bits 
>>> para 64 bits.
>>> 
>>> Esse efeito que tu teve não é somente facilmente previsto, é uma certeza.
>>> 
>>> 
>>> 
>>> -- 
>>> Att. Dane Everson
>>> Atua Sistemas de Informação
>>> Skype: dane.atua
>>> Msn: d...@atua.com.br
>>> Fone: (54) 3045-4044
>>> Celular: (54) 9905-5712
>>> Linux User #548369
>>> 
>>> 
>>> 
>>> -- 
>>> To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
>>> with a subject of "unsubscribe". Trouble? Contact 
>>> listmas...@lists.debian.org
>>> Archive: http://lists.debian.org/4f86d8b6.4040...@atua.com.br
>>> 
>>> 
>> 
>> -- 
>> Att. Dane Everson
>> Atua Sistemas de Informação
>> Skype: dane.atua
>> Msn: d...@atua.com.br
>> Fone: (54) 3045-4044
>> Celular: (54) 9905-5712
>> Linux User #548369
> 
> 
> -- 
> ---
> SLot
> Linux User: 124842
> XMPP: s...@jabber-br.org | slot...@gmail.com

Re: Cobol

[Dane Brand]

Pois é , já configurei a as lib32, mas não resolveu! 

O executável esta usando as libs do /lib32 



Dane Brand

Em 12/04/2012, às 12:38, Listeiro 037  escreveu:

> Olá.
> 
> Você sabe se a glibc/libstdc++ de 32 bits está instalada no sistema de
> 64 bits?
> 
> 
> 
> 
> Em Thu, 12 Apr 2012 11:19:26 -0300
> Dane  escreveu:
> 
>> Imaginei isto, mas queria trocar uma ideia com vcs, até pq alguém 
>> poderia ter passado por isto.
>> 
>> Mas mto obrigado pessoal.
>> 
>> Em 12-04-2012 11:16, Gustavo Soares [SLot] escreveu:
>>> Amigo, é exatamente que o P.J está tentando te falar.  O seu
>>> sistema não irá funcionar como você quer, simplesmente fazendo
>>> upgrade do hardware, o lance aí é mais embaixo, é no cobol.
>>> 
>>> Creio que você não terá muito o que fazer no linux ou no hardware.
>>> 
>>> 
>>> 
>>> Em 12-04-2012 11:03, Dane escreveu:
 Pessoal, eu não sou desenvolvedor, sou da Infra.
 
 Mas vejam, eu não quero aumentar o desempenho, não quero usar 
 threads, gostaria de algum todas as aplicações estão rodando 
 normalmente.
 
 Só gostaria se alguém souber me afirmar o pq um processo está
 usando 1% da cpu, quais podem ser os motivos para isto.
 
 Obrigado.
 
 Em 12-04-2012 10:39, Rodolfo escreveu:
> Quais aplicações ? Tem como listar ?
> E porque não migram pra Java ?
> E como falaram ali em cima, você aparentemente usava uma
> aplicação desenvolvida pra rodar em 32 bits, logo, quando usa em
> 64 bits, o funcionamente não será o mesmo, precisa recompilar o
> mesmo para 64 bits. Abraços.
> 
> Em 12 de abril de 2012 09:29, Dane  > escreveu:
> 
>Não ficou muito claro, pelo seguinte, eu só tenho problema em
>algumas aplicações e qual a referência disto com o uso do
>processador?
> 
>Em 12-04-2012 10:10, Iuri Guilherme dos Santos Martins
> escreveu:
> 
>Em 12-04-2012 09:59, Dane escreveu:
> 
>Olá Iuri,
> 
>Você já teve algum problema parecido?
> 
>Está mesmo relacionado a arquitetura?
> 
> 
>Não.
> 
>Um programa escrito em Cobol depende da configuração da
>máquina. Não é Java, é Cobol.
> 
>Se tu mudar o processador ou alguma outra parte do
> hardware sem alterar o código fonte do programa, ele vai se
> comportar de forma diferente.
> 
>Principalmente quando tu muda de uma arquitetura de
>processador de 32 bits para 64 bits.
> 
>Esse efeito que tu teve não é somente facilmente
> previsto, é uma certeza.
> 
> 
> 
>-- 
>Att. Dane Everson
>Atua Sistemas de Informação
>Skype: dane.atua
>Msn: d...@atua.com.br 
>Fone: (54) 3045-4044
>Celular: (54) 9905-5712
>Linux User #548369
> 
> 
> 
>-- 
>To UNSUBSCRIBE, email to
>debian-user-portuguese-requ...@lists.debian.org
>
>with a subject of "unsubscribe". Trouble? Contact
>listmas...@lists.debian.org
>  Archive:
> http://lists.debian.org/4f86d8b6.4040...@atua.com.br
> 
> 
 
 -- 
 Att. Dane Everson
 Atua Sistemas de Informação
 Skype: dane.atua
 Msn:d...@atua.com.br
 Fone: (54) 3045-4044
 Celular: (54) 9905-5712
 Linux User #548369
>>> 
>>> 
>>> -- 
>>> ---
>>> SLot
>>> Linux User: 124842
>>> XMPP:s...@jabber-br.org  |slot...@gmail.com
>> 
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/20120412123804.13d65...@yahoo.com.br
> 


--
To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/07bdd51c-9032-47bf-8039-0bfb2da91...@gmail.com

Re: Cobol

[Dane Brand]

Cara concordo plenamente com vc.

Talvez o sentido da experiência a qual me referi não foi exatamente como vc 
tinha entendido.

Obrigado pela sua resposta.

Dane Brand

Em 12/04/2012, às 12:12, Iuri Guilherme dos Santos Martins 
 escreveu:

> Bom talvez eu não tenha esclarecido bem
> 
> Eu sou da área de desenvolvimento, e eu posso te dizer tudo o que eu disse e 
> os outros disseram aqui:
> 
> O motivo do teu software não se comportar conforme o esperado é que ele 
> certamente deve ter sido desenvolvido para outra arquitetura de processador 
> (32 bits e 64 bits são especificações de arquitetura de processador ou CPU).
> 
> Eu não preciso ter passado por esta experiência para saber disto. Isso é 
> conhecimento comum no meio da computação.
> 
> Se for o caso de ter passado por algo semelhante, já passei sim, considerando 
> que eu preciso passar por um trabalho de alterar o código fonte de um 
> software e portar para outra arquitetura (32 para 64 bits) quando eu quero 
> por exemplo fazer um jogo de Windows 95/98 rodar em um Windows 7 feito para 
> arquitetura de 64 bits. Todas as vezes que eu quero fazer isso eu passo por 
> esta "experiência".
> 
> Repetindo, a única forma de fazer o software se comportar conforme o esperado 
> é reescrever o código e compilar ele novamente. Tu vai ter que achar o cara 
> (ou a empresa, que da na mesma porque sempre é uma pessoa só) que desenvolveu 
> o software e perguntar se tem como portar o software para outra arquitetura. 
> Existe 99% de probabilidade da resposta ser negativa. Mas tu também pode 
> chamar outro desenvolvedor em Cobol que ou vai se recusar a fazer o serviço 
> ou vai estipular um prazo e um custo que talvez tu não esteja disposto a 
> esperar / financiar.
> 
> Ou então pode ser que seja uma coisa tão fácil que possa ser feito de forma 
> rápida e com pouco custo. Só analisando o software pra poder dizer isso.
> 
> Não tem um tutorial ou experiência de outra pessoa que vai te ajudar nisso a 
> não ser alterar o software.
> 
> Acho que isso deve esclarecer melhor o que eu respondi na pressa antes.
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/4f86f0f2.80...@gmail.com
> 


--
To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/6df12b95-d55f-4c4a-848d-53cec8e49...@gmail.com

Re: Cobol

[Listeiro 037]

Olá.

Você sabe se a glibc/libstdc++ de 32 bits está instalada no sistema de
64 bits?




Em Thu, 12 Apr 2012 11:19:26 -0300
Dane  escreveu:

> Imaginei isto, mas queria trocar uma ideia com vcs, até pq alguém 
> poderia ter passado por isto.
> 
> Mas mto obrigado pessoal.
> 
> Em 12-04-2012 11:16, Gustavo Soares [SLot] escreveu:
> > Amigo, é exatamente que o P.J está tentando te falar.  O seu
> > sistema não irá funcionar como você quer, simplesmente fazendo
> > upgrade do hardware, o lance aí é mais embaixo, é no cobol.
> >
> > Creio que você não terá muito o que fazer no linux ou no hardware.
> >
> >
> >
> > Em 12-04-2012 11:03, Dane escreveu:
> >> Pessoal, eu não sou desenvolvedor, sou da Infra.
> >>
> >> Mas vejam, eu não quero aumentar o desempenho, não quero usar 
> >> threads, gostaria de algum todas as aplicações estão rodando 
> >> normalmente.
> >>
> >> Só gostaria se alguém souber me afirmar o pq um processo está
> >> usando 1% da cpu, quais podem ser os motivos para isto.
> >>
> >> Obrigado.
> >>
> >> Em 12-04-2012 10:39, Rodolfo escreveu:
> >>> Quais aplicações ? Tem como listar ?
> >>> E porque não migram pra Java ?
> >>> E como falaram ali em cima, você aparentemente usava uma
> >>> aplicação desenvolvida pra rodar em 32 bits, logo, quando usa em
> >>> 64 bits, o funcionamente não será o mesmo, precisa recompilar o
> >>> mesmo para 64 bits. Abraços.
> >>>
> >>> Em 12 de abril de 2012 09:29, Dane  >>> > escreveu:
> >>>
> >>> Não ficou muito claro, pelo seguinte, eu só tenho problema em
> >>> algumas aplicações e qual a referência disto com o uso do
> >>> processador?
> >>>
> >>> Em 12-04-2012 10:10, Iuri Guilherme dos Santos Martins
> >>> escreveu:
> >>>
> >>> Em 12-04-2012 09:59, Dane escreveu:
> >>>
> >>> Olá Iuri,
> >>>
> >>> Você já teve algum problema parecido?
> >>>
> >>> Está mesmo relacionado a arquitetura?
> >>>
> >>>
> >>> Não.
> >>>
> >>> Um programa escrito em Cobol depende da configuração da
> >>> máquina. Não é Java, é Cobol.
> >>>
> >>> Se tu mudar o processador ou alguma outra parte do
> >>> hardware sem alterar o código fonte do programa, ele vai se
> >>> comportar de forma diferente.
> >>>
> >>> Principalmente quando tu muda de uma arquitetura de
> >>> processador de 32 bits para 64 bits.
> >>>
> >>> Esse efeito que tu teve não é somente facilmente
> >>> previsto, é uma certeza.
> >>>
> >>>
> >>>
> >>> -- 
> >>> Att. Dane Everson
> >>> Atua Sistemas de Informação
> >>> Skype: dane.atua
> >>> Msn: d...@atua.com.br 
> >>> Fone: (54) 3045-4044
> >>> Celular: (54) 9905-5712
> >>> Linux User #548369
> >>>
> >>>
> >>>
> >>> -- 
> >>> To UNSUBSCRIBE, email to
> >>> debian-user-portuguese-requ...@lists.debian.org
> >>> 
> >>> with a subject of "unsubscribe". Trouble? Contact
> >>> listmas...@lists.debian.org
> >>>  Archive:
> >>> http://lists.debian.org/4f86d8b6.4040...@atua.com.br
> >>>
> >>>
> >>
> >> -- 
> >> Att. Dane Everson
> >> Atua Sistemas de Informação
> >> Skype: dane.atua
> >> Msn:d...@atua.com.br
> >> Fone: (54) 3045-4044
> >> Celular: (54) 9905-5712
> >> Linux User #548369
> >
> >
> > -- 
> > ---
> > SLot
> > Linux User: 124842
> > XMPP:s...@jabber-br.org  |slot...@gmail.com
> 


--
To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120412123804.13d65...@yahoo.com.br

Re: Cobol

[Iuri Guilherme dos Santos Martins]

Bom talvez eu não tenha esclarecido bem

Eu sou da área de desenvolvimento, e eu posso te dizer tudo o que eu 
disse e os outros disseram aqui:


O motivo do teu software não se comportar conforme o esperado é que ele 
certamente deve ter sido desenvolvido para outra arquitetura de 
processador (32 bits e 64 bits são especificações de arquitetura de 
processador ou CPU).


Eu não preciso ter passado por esta experiência para saber disto. Isso é 
conhecimento comum no meio da computação.


Se for o caso de ter passado por algo semelhante, já passei sim, 
considerando que eu preciso passar por um trabalho de alterar o código 
fonte de um software e portar para outra arquitetura (32 para 64 bits) 
quando eu quero por exemplo fazer um jogo de Windows 95/98 rodar em um 
Windows 7 feito para arquitetura de 64 bits. Todas as vezes que eu quero 
fazer isso eu passo por esta "experiência".


Repetindo, a única forma de fazer o software se comportar conforme o 
esperado é reescrever o código e compilar ele novamente. Tu vai ter que 
achar o cara (ou a empresa, que da na mesma porque sempre é uma pessoa 
só) que desenvolveu o software e perguntar se tem como portar o software 
para outra arquitetura. Existe 99% de probabilidade da resposta ser 
negativa. Mas tu também pode chamar outro desenvolvedor em Cobol que ou 
vai se recusar a fazer o serviço ou vai estipular um prazo e um custo 
que talvez tu não esteja disposto a esperar / financiar.


Ou então pode ser que seja uma coisa tão fácil que possa ser feito de 
forma rápida e com pouco custo. Só analisando o software pra poder dizer 
isso.


Não tem um tutorial ou experiência de outra pessoa que vai te ajudar 
nisso a não ser alterar o software.


Acho que isso deve esclarecer melhor o que eu respondi na pressa antes.


--
To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f86f0f2.80...@gmail.com

Re: Cobol

[Rodolfo]

Não conheço o seu ambiente, mas pode ter certeza, Cobol é o ponto de
partida, partindo desse princípio, verifique com os desenvolvedores do
software a solução  para a possível falha.

Em 12 de abril de 2012 10:19, Dane  escreveu:

> Imaginei isto, mas queria trocar uma ideia com vcs, até pq alguém poderia
> ter passado por isto.
>
> Mas mto obrigado pessoal.
>
> Em 12-04-2012 11:16, Gustavo Soares [SLot] escreveu:
>
> Amigo, é exatamente que o P.J está tentando te falar.  O seu sistema não
> irá funcionar como você quer, simplesmente fazendo upgrade do hardware, o
> lance aí é mais embaixo, é no cobol.
>
> Creio que você não terá muito o que fazer no linux ou no hardware.
>
>
>
> Em 12-04-2012 11:03, Dane escreveu:
>
> Pessoal, eu não sou desenvolvedor, sou da Infra.
>
> Mas vejam, eu não quero aumentar o desempenho, não quero usar threads,
> gostaria de algum todas as aplicações estão rodando normalmente.
>
> Só gostaria se alguém souber me afirmar o pq um processo está usando 1% da
> cpu, quais podem ser os motivos para isto.
>
> Obrigado.
>
> Em 12-04-2012 10:39, Rodolfo escreveu:
>
> Quais aplicações ? Tem como listar ?
>
> E porque não migram pra Java ?
>
>
> E como falaram ali em cima, você aparentemente usava uma aplicação
> desenvolvida pra rodar em 32 bits, logo, quando usa em 64 bits, o
> funcionamente não será o mesmo, precisa recompilar o mesmo para 64 bits.
>
>
> Abraços.
>
> Em 12 de abril de 2012 09:29, Dane  escreveu:
>
>> Não ficou muito claro, pelo seguinte, eu só tenho problema em algumas
>> aplicações e qual a referência disto com o uso do processador?
>>
>> Em 12-04-2012 10:10, Iuri Guilherme dos Santos Martins escreveu:
>>
>> Em 12-04-2012 09:59, Dane escreveu:
>>>
 Olá Iuri,

 Você já teve algum problema parecido?

 Está mesmo relacionado a arquitetura?

>>>
>>> Não.
>>>
>>> Um programa escrito em Cobol depende da configuração da máquina. Não é
>>> Java, é Cobol.
>>>
>>> Se tu mudar o processador ou alguma outra parte do hardware sem alterar
>>> o código fonte do programa, ele vai se comportar de forma diferente.
>>>
>>> Principalmente quando tu muda de uma arquitetura de processador de 32
>>> bits para 64 bits.
>>>
>>> Esse efeito que tu teve não é somente facilmente previsto, é uma certeza.
>>>
>>>
>>>
>> --
>> Att. Dane Everson
>> Atua Sistemas de Informação
>> Skype: dane.atua
>> Msn: d...@atua.com.br
>> Fone: (54) 3045-4044
>> Celular: (54) 9905-5712
>> Linux User #548369
>>
>>
>>
>> --
>> To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
>> with a subject of "unsubscribe". Trouble? Contact
>> listmas...@lists.debian.org
>> Archive: http://lists.debian.org/4f86d8b6.4040...@atua.com.br
>>
>>
>
> --
> Att. Dane Everson
> Atua Sistemas de Informação
> Skype: dane.atua
> Msn: d...@atua.com.br
> Fone: (54) 3045-4044
> Celular: (54) 9905-5712
> Linux User #548369
>
>
>
> --
> ---
> SLot
> Linux User: 124842
> XMPP: s...@jabber-br.org | slot...@gmail.com
>
>
> --
> Att. Dane Everson
> Atua Sistemas de Informação
> Skype: dane.atua
> Msn: d...@atua.com.br
> Fone: (54) 3045-4044
> Celular: (54) 9905-5712
> Linux User #548369
>
>

Re: Cobol

[Dane]

Imaginei isto, mas queria trocar uma ideia com vcs, até pq alguém 
poderia ter passado por isto.


Mas mto obrigado pessoal.

Em 12-04-2012 11:16, Gustavo Soares [SLot] escreveu:
Amigo, é exatamente que o P.J está tentando te falar.  O seu sistema 
não irá funcionar como você quer, simplesmente fazendo upgrade do 
hardware, o lance aí é mais embaixo, é no cobol.


Creio que você não terá muito o que fazer no linux ou no hardware.



Em 12-04-2012 11:03, Dane escreveu:

Pessoal, eu não sou desenvolvedor, sou da Infra.

Mas vejam, eu não quero aumentar o desempenho, não quero usar 
threads, gostaria de algum todas as aplicações estão rodando 
normalmente.


Só gostaria se alguém souber me afirmar o pq um processo está usando 
1% da cpu, quais podem ser os motivos para isto.


Obrigado.

Em 12-04-2012 10:39, Rodolfo escreveu:

Quais aplicações ? Tem como listar ?
E porque não migram pra Java ?
E como falaram ali em cima, você aparentemente usava uma aplicação 
desenvolvida pra rodar em 32 bits, logo, quando usa em 64 bits, o 
funcionamente não será o mesmo, precisa recompilar o mesmo para 64 bits.

Abraços.

Em 12 de abril de 2012 09:29, Dane > escreveu:


Não ficou muito claro, pelo seguinte, eu só tenho problema em
algumas aplicações e qual a referência disto com o uso do
processador?

Em 12-04-2012 10:10, Iuri Guilherme dos Santos Martins escreveu:

Em 12-04-2012 09:59, Dane escreveu:

Olá Iuri,

Você já teve algum problema parecido?

Está mesmo relacionado a arquitetura?


Não.

Um programa escrito em Cobol depende da configuração da
máquina. Não é Java, é Cobol.

Se tu mudar o processador ou alguma outra parte do hardware
sem alterar o código fonte do programa, ele vai se comportar
de forma diferente.

Principalmente quando tu muda de uma arquitetura de
processador de 32 bits para 64 bits.

Esse efeito que tu teve não é somente facilmente previsto, é
uma certeza.



-- 
Att. Dane Everson

Atua Sistemas de Informação
Skype: dane.atua
Msn: d...@atua.com.br 
Fone: (54) 3045-4044
Celular: (54) 9905-5712
Linux User #548369



-- 
To UNSUBSCRIBE, email to

debian-user-portuguese-requ...@lists.debian.org

with a subject of "unsubscribe". Trouble? Contact
listmas...@lists.debian.org 
Archive: http://lists.debian.org/4f86d8b6.4040...@atua.com.br




--
Att. Dane Everson
Atua Sistemas de Informação
Skype: dane.atua
Msn:d...@atua.com.br
Fone: (54) 3045-4044
Celular: (54) 9905-5712
Linux User #548369



--
---
SLot
Linux User: 124842
XMPP:s...@jabber-br.org  |slot...@gmail.com


--
Att. Dane Everson
Atua Sistemas de Informação
Skype: dane.atua
Msn: d...@atua.com.br
Fone: (54) 3045-4044
Celular: (54) 9905-5712
Linux User #548369

Re: Cobol

[Dane]

Em 12-04-2012 11:10, P. J. escreveu:

Em 12 de abril de 2012 11:03, Dane  escreveu:

Pessoal, eu não sou desenvolvedor, sou da Infra.


Isso independente de ser de infra ou desenvolvimento... técnico ou
acadêmico "deveriam" ser conhecimentos básicos... (sem ofensas...).


Não me ofende pq não tem moral esse comentário, isso é uma resposta 
sobre o comentário do nosso colega sobre migrar para Java, entre outros 
detalhes que cabe ao desenvolvedor da aplicação.



Só gostaria se alguém souber me afirmar o pq um processo está usando 1% da
cpu, quais podem ser os motivos para isto.

Velho existem n variáveis
Esse é o grande x, imaginei que tivesse alguém com alguma experiência 
parecida.




--
Att. Dane Everson
Atua Sistemas de Informação
Skype: dane.atua
Msn: d...@atua.com.br
Fone: (54) 3045-4044
Celular: (54) 9905-5712
Linux User #548369


--
To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f86e423.1050...@atua.com.br

Re: Cobol

[P. J.]

já que vc não é desenvolvedor... converse com o pessoal e detalhe
mais... pq assim fica muito solto... a não ser q fique nesse loop de
"especulação" e "achismo"...

peço desculpas... sem querer mandei a msg anterior sem terminar...

Abs

-- 
|  .''`.   A fé não dá respostas. Só impede perguntas.
| : :'  :
| `. `'`
|   `-   P.J. - http://wiki.dcc.ufba.br/~PeeJay


--
To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CACnf0pj7VEr8gkmOeE=a_zAgQyFesWJTbFwVh=ttqe5g1...@mail.gmail.com

Re: Cobol

[Gustavo Soares [SLot]]

Amigo, é exatamente que o P.J está tentando te falar.  O seu sistema não 
irá funcionar como você quer, simplesmente fazendo upgrade do hardware, 
o lance aí é mais embaixo, é no cobol.


Creio que você não terá muito o que fazer no linux ou no hardware.



Em 12-04-2012 11:03, Dane escreveu:

Pessoal, eu não sou desenvolvedor, sou da Infra.

Mas vejam, eu não quero aumentar o desempenho, não quero usar threads, 
gostaria de algum todas as aplicações estão rodando normalmente.


Só gostaria se alguém souber me afirmar o pq um processo está usando 
1% da cpu, quais podem ser os motivos para isto.


Obrigado.

Em 12-04-2012 10:39, Rodolfo escreveu:

Quais aplicações ? Tem como listar ?
E porque não migram pra Java ?
E como falaram ali em cima, você aparentemente usava uma aplicação 
desenvolvida pra rodar em 32 bits, logo, quando usa em 64 bits, o 
funcionamente não será o mesmo, precisa recompilar o mesmo para 64 bits.

Abraços.

Em 12 de abril de 2012 09:29, Dane > escreveu:


Não ficou muito claro, pelo seguinte, eu só tenho problema em
algumas aplicações e qual a referência disto com o uso do
processador?

Em 12-04-2012 10:10, Iuri Guilherme dos Santos Martins escreveu:

Em 12-04-2012 09:59, Dane escreveu:

Olá Iuri,

Você já teve algum problema parecido?

Está mesmo relacionado a arquitetura?


Não.

Um programa escrito em Cobol depende da configuração da
máquina. Não é Java, é Cobol.

Se tu mudar o processador ou alguma outra parte do hardware
sem alterar o código fonte do programa, ele vai se comportar
de forma diferente.

Principalmente quando tu muda de uma arquitetura de
processador de 32 bits para 64 bits.

Esse efeito que tu teve não é somente facilmente previsto, é
uma certeza.



-- 
Att. Dane Everson

Atua Sistemas de Informação
Skype: dane.atua
Msn: d...@atua.com.br 
Fone: (54) 3045-4044
Celular: (54) 9905-5712
Linux User #548369



-- 
To UNSUBSCRIBE, email to

debian-user-portuguese-requ...@lists.debian.org

with a subject of "unsubscribe". Trouble? Contact
listmas...@lists.debian.org 
Archive: http://lists.debian.org/4f86d8b6.4040...@atua.com.br




--
Att. Dane Everson
Atua Sistemas de Informação
Skype: dane.atua
Msn:d...@atua.com.br
Fone: (54) 3045-4044
Celular: (54) 9905-5712
Linux User #548369



--
---
SLot
Linux User: 124842
XMPP: s...@jabber-br.org | slot...@gmail.com

Re: Cobol

[P. J.]

Em 12 de abril de 2012 11:03, Dane  escreveu:
> Pessoal, eu não sou desenvolvedor, sou da Infra.
>

Isso independente de ser de infra ou desenvolvimento... técnico ou
acadêmico "deveriam" ser conhecimentos básicos... (sem ofensas...).

> Só gostaria se alguém souber me afirmar o pq um processo está usando 1% da
> cpu, quais podem ser os motivos para isto.

Velho existem n variáveis

-- 
|  .''`.   A fé não dá respostas. Só impede perguntas.
| : :'  :
| `. `'`
|   `-   P.J. - http://wiki.dcc.ufba.br/~PeeJay


--
To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CACnf0pgy2ihE6XoPAGBa7RcqJgmOhrZkn=ha7fbtrhpsoua...@mail.gmail.com

Re: Cobol

[Dane]

Pessoal, eu não sou desenvolvedor, sou da Infra.

Mas vejam, eu não quero aumentar o desempenho, não quero usar threads, 
gostaria de algum todas as aplicações estão rodando normalmente.


Só gostaria se alguém souber me afirmar o pq um processo está usando 1% 
da cpu, quais podem ser os motivos para isto.


Obrigado.

Em 12-04-2012 10:39, Rodolfo escreveu:

Quais aplicações ? Tem como listar ?
E porque não migram pra Java ?
E como falaram ali em cima, você aparentemente usava uma aplicação 
desenvolvida pra rodar em 32 bits, logo, quando usa em 64 bits, o 
funcionamente não será o mesmo, precisa recompilar o mesmo para 64 bits.

Abraços.

Em 12 de abril de 2012 09:29, Dane > escreveu:


Não ficou muito claro, pelo seguinte, eu só tenho problema em
algumas aplicações e qual a referência disto com o uso do processador?

Em 12-04-2012 10:10, Iuri Guilherme dos Santos Martins escreveu:

Em 12-04-2012 09:59, Dane escreveu:

Olá Iuri,

Você já teve algum problema parecido?

Está mesmo relacionado a arquitetura?


Não.

Um programa escrito em Cobol depende da configuração da
máquina. Não é Java, é Cobol.

Se tu mudar o processador ou alguma outra parte do hardware
sem alterar o código fonte do programa, ele vai se comportar
de forma diferente.

Principalmente quando tu muda de uma arquitetura de
processador de 32 bits para 64 bits.

Esse efeito que tu teve não é somente facilmente previsto, é
uma certeza.



-- 
Att. Dane Everson

Atua Sistemas de Informação
Skype: dane.atua
Msn: d...@atua.com.br 
Fone: (54) 3045-4044
Celular: (54) 9905-5712
Linux User #548369



-- 
To UNSUBSCRIBE, email to

debian-user-portuguese-requ...@lists.debian.org

with a subject of "unsubscribe". Trouble? Contact
listmas...@lists.debian.org 
Archive: http://lists.debian.org/4f86d8b6.4040...@atua.com.br




--
Att. Dane Everson
Atua Sistemas de Informação
Skype: dane.atua
Msn: d...@atua.com.br
Fone: (54) 3045-4044
Celular: (54) 9905-5712
Linux User #548369

Re: Aplicativo para mensagens tipo "netsend"

[Kleber Melo]

  
  
Em 04/11/2012 08:52 PM, henrique escreveu:

  
smbclient -M ip-da-estacao 



para ler mensagens netsend no linux, coloque um 



message command = /bin/sh -c '/usr/bin/xedit %s; rm %s'
  & 



no seu smb.conf 



ah, e um " xhost + " nos scripts de inicialização do 
  usuário desktop. 



p.s.: tecnicamente vc poderia até chamar o openoffice para
  ler o arquivo que ficará em %s. Fica a seu critério escolher
  algo do seu agrado :D 





de unix para unix, eu prefiro o talk mesmo. Tem o talk,
  xchat, ytalk.


[ ] 's, 

Henry





  

  
 
 De:
Kleber Melo 
Para:
Debian BR
 
Enviadas:
Quarta-feira, 11 de Abril de 2012 19:35
Assunto:
Aplicativo para mensagens tipo "netsend"
   


   Boa noite!
  Alguém conhece/usa algum comunicador interno, sem
  ser e-mail ou openfire, que possa mandar
  mensagens, tipo o netsend do rWindows? Gostaria de
  fazer uns testes aqui na empresa e gostaria de uma
  sugestão!
  Abraços a todos

-- 

Kleber Melo
Admin. Sistemas Linux
Advanced Level - Linux Professional Institute Certificate (LPIC-2)
Novell Certified Linux Administrator (CLA)
Novell Data Center Technical Specialist (DCT)



  
  -- To UNSUBSCRIBE, email to
  debian-user-portuguese-requ...@lists.debian.org
  with a subject of "unsubscribe". Trouble? Contact
  listmas...@lists.debian.org
  Archive:
  http://lists.debian.org/4f860722.6040...@yahoo.com.br



  

  

  

Valeu Henrique, irei efetuar os testes
aqui no ambiente!
Abraços

-- 

Kleber Melo
Admin. Sistemas Linux
Advanced Level - Linux Professional Institute Certificate (LPIC-2)
Novell Certified Linux Administrator (CLA)
Novell Data Center Technical Specialist (DCT)
  



-- 
To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f86d910.5010...@yahoo.com.br

Re: Cobol

[P. J.]

Se não houve alteração de código ele vai continuar a rodar na
plataforma de 32 bits(supondo q ela é dessa arquitetura)... e outra vc
nao disse oq sua aplicação faz para consumir 100% de uma máquina de um
núcleo só...

Vc alterar hardware e o SO de  não vai ter o efeito desejado... para
ter o efeito desejado ou vc porta sua aplicação para 64 bits (para ter
mais RAM tb)... mas aí tem que ver questões de portabilidade e
talzs... ou então vê se existe a possibilidade de se trabalhar com
paralelismo, i.e, se a linguagem tem  suporte a thread... verificando
se o custo de gerenciamento das threads nao é alto... mas por alto e
"por chute" é problema de implementação...

-- 
|  .''`.   A fé não dá respostas. Só impede perguntas.
| : :'  :
| `. `'`
|   `-   P.J. - http://wiki.dcc.ufba.br/~PeeJay


--
To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cacnf0pglsbm874na6rwduvx+eddz_owye8oobq5ofuzzmyi...@mail.gmail.com

Re: Cobol

[Dane]

Não ficou muito claro, pelo seguinte, eu só tenho problema em algumas 
aplicações e qual a referência disto com o uso do processador?


Em 12-04-2012 10:10, Iuri Guilherme dos Santos Martins escreveu:

Em 12-04-2012 09:59, Dane escreveu:

Olá Iuri,

Você já teve algum problema parecido?

Está mesmo relacionado a arquitetura?


Não.

Um programa escrito em Cobol depende da configuração da máquina. Não é 
Java, é Cobol.


Se tu mudar o processador ou alguma outra parte do hardware sem 
alterar o código fonte do programa, ele vai se comportar de forma 
diferente.


Principalmente quando tu muda de uma arquitetura de processador de 32 
bits para 64 bits.


Esse efeito que tu teve não é somente facilmente previsto, é uma certeza.




--
Att. Dane Everson
Atua Sistemas de Informação
Skype: dane.atua
Msn: d...@atua.com.br
Fone: (54) 3045-4044
Celular: (54) 9905-5712
Linux User #548369


--
To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f86d8b6.4040...@atua.com.br

Re: Cobol

[Iuri Guilherme dos Santos Martins]

Em 12-04-2012 09:59, Dane escreveu:

Olá Iuri,

Você já teve algum problema parecido?

Está mesmo relacionado a arquitetura?


Não.

Um programa escrito em Cobol depende da configuração da máquina. Não é 
Java, é Cobol.


Se tu mudar o processador ou alguma outra parte do hardware sem alterar 
o código fonte do programa, ele vai se comportar de forma diferente.


Principalmente quando tu muda de uma arquitetura de processador de 32 
bits para 64 bits.


Esse efeito que tu teve não é somente facilmente previsto, é uma certeza.


--
To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f86d431.3060...@gmail.com

Re: Cobol

[Dane]

Olá Iuri,

Você já teve algum problema parecido?

Está mesmo relacionado a arquitetura?

mto obrigado

Em 12 de abril de 2012 09:56, Iuri Guilherme dos Santos Martins <
iuri.guilherme@gmail.com> escreveu:

> A tua única chance é alterar o código do sistema. Se tu não programa em
> Cobol e tiver que contratar alguém isso vai ser meio caro.
>
> Dependendo da natureza do sistema e da quantidade de código, pode ser que
> migrar o código de um hardware para outro seja mais caro do que o que tu
> iria economizar com hardware diferente, nem sempre vale a pena fazer essa
> migração.
>
>
> --
> To UNSUBSCRIBE, email to 
> debian-user-portuguese-**requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: 
> http://lists.debian.org/**4f86d111@gmail.com
>
>

Re: Cobol

[Iuri Guilherme dos Santos Martins]

A tua única chance é alterar o código do sistema. Se tu não programa em 
Cobol e tiver que contratar alguém isso vai ser meio caro.


Dependendo da natureza do sistema e da quantidade de código, pode ser 
que migrar o código de um hardware para outro seja mais caro do que o 
que tu iria economizar com hardware diferente, nem sempre vale a pena 
fazer essa migração.



--
To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f86d111@gmail.com