I use the same editor for everything and have been using it for some 30+
years.  It’s a bit buggy on Windows Server 2008 - it had its own Virtual
Memory code and occasionally one thread spins up), but otherwise works OK.
Last I looked they still have only one version updated some time ago.  

It comes from the IBM Mainframe and so was probably the first full screen
editor around.  My first use was around 1978 just after "TSO Edit" a line
mode editor - and yes - punched card decks!  

It is written by an independent company (IBM's own PC port attempt was a
miserable failure), can handle any size file, UNIX, DOS line endings, can
edit binaries, etc.  It has limited mouse support, no graphics.  Its
"original" name was ISPF (on MVS) or even further back SPF which stands for
"(Interactive) Structured Programming Facility".  

The company that sells it is Command Technology Corp.
www.commandtechnology.com  It is rather obtuse if you don't already know it
- i.e. have a solid mainframe programming background.  

Yes, I use all of the standard tools like grep, egrep, head, tail, bash,
cut, etc, and, heaven forbid, notepad or vi when I absolutely have to.
See www.cygwin.com for the whole set.

For Meta-Update script images (i.e. documentation) - I use a free Notepad++
which is useful for highlighting and colouring bits of text.

I always carry "SPF/Pro" around and transfer files to and from Windows just
to be able to edit with my editor (from many different OS's over the time I
have been working) .  

I have seen no other editor with a single most important feature that I
like, the ability to hide all lines of a file and selectively display lines
based on finds.  SPF still supports "REXX Macros" for extensions and comes
with a few (such as finding a terminating ')' or '}').  The hex edit feature
is also very useful.

I think your editor shows something about your personality.  I worked in a
company where most (c) developers used an editor (Brief) by "Underwear Inc"
- http://en.wikipedia.org/wiki/Brief_(text_editor).  Two of us on the PC
code side used SPF and the single assembler programmer also used SPF -
really still the only choice on a mainframe.

I also tend to work with DOS boxes to give me filters, fields, queries, SQL
queries, etc dynamically with my own binaries.  I am a big cygwin user and
also carry it around on a stick.

This was a fun post!

Cheers
Ben Chernys

Senior Software Architect
Software Tool House Inc.

Canada / Deutschland / Germany
Mobile:      +49 171 380 2329    GMT + 1 + [ DST ]
Email:       ben.cher...@softwaretoolhouse.com
Web:         www.softwaretoolhouse.com

Check out Software Tool House's free Diary Editor.

Meta-Update, our premium ARS Data tool, lets you automate 
your imports, migrations, in no time at all, without programming, 
without staging forms, without merge workflow. 
http://www.softwaretoolhouse.com/  


-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arsl...@arslist.org] On Behalf Of Jarl Grøneng
Sent: April 22, 2010 9:06 PM
To: arslist@ARSLIST.ORG
Subject: Re: Log size and server performance

Less is more :-)


Also adding head and tail....

--
Jarl

2010/4/22 Grooms, Frederick W <frederick.w.gro...@xo.com>:
> On Solaris I prefer less instead of more
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList) 
> [mailto:arsl...@arslist.org] On Behalf Of Jarl Grøneng
> Sent: Thursday, April 22, 2010 1:15 PM
> To: arslist@ARSLIST.ORG
> Subject: Re: Log size and server performance
>
> Windows; BareTail and BareGrep
> Solaris: cat, grep and more
>
> --
> Jarl
>
> 2010/4/22 John Sundberg <john.sundb...@kineticdata.com>:
>> **
>> Speaking of logs -- what do people use to read them?
>> Does anybody use splunk -- do you like it -- does it help?
>> -John
>>
>>
>>
>> On Apr 21, 2010, at 4:57 PM, Grooms, Frederick W wrote:
>> **
>> And since Anne is on Linux she can set up a cron job to archive the 
>> logs every 5 (or 10) minutes.   I do that currently on production so 
>> I can always go back a complete day in the logs.
>>
>> Fred
>>
>> From: Action Request System discussion list(ARSList) 
>> [mailto:arsl...@arslist.org] on Behalf Of Benedetto Cantatore
>> Sent: Wednesday, April 21, 2010 3:59 PM
>> To: arsl...@arslist.org
>> Subject: Re: Log size and server performance
>>
>> **
>> I found 500 megs to be a good size.  I can usually capture what I'm 
>> looking for within a 10-15 minute window.
>>
>> Ben Cantatore
>> Remedy Manager
>> (914) 457-6209
>>
>> Emerging Health IT
>> 3 Odell Plaza
>> Yonkers, New York 10701
>>>>> anne.ra...@its.nc.gov 04/21/10 12:29 PM >>>
>> **
>> I ask because I know appending to a 1 G file takes a lot longer (in 
>> computer
>> time) than appending to a 1 M file.  I was wondering if anyone was 
>> aware of a practical limit?
>>
>>
>> Anne Ramey
>>
>> E-mail correspondence to and from this address may be subject to the 
>> North Carolina Public Records Law and may be disclosed to third 
>> parties only by an authorized State Official.
>>
>> From: Action Request System discussion list(ARSList) 
>> [mailto:arsl...@arslist.org] on Behalf Of Lyle Taylor
>> Sent: Wednesday, April 21, 2010 12:09 PM
>> To: arsl...@arslist.org
>> Subject: Re: Log size and server performance
>>
>> **
>> Well, this isn't a definitive answer by any means, but my suspicion 
>> would be that the log file size should be pretty much irrelevant from 
>> a performance perspective, since it is just appending to the existing 
>> file, which is a quick operation.  The more important point is that 
>> if you're getting that much logging output, just having logging on at 
>> all is probably impacting performance on the server.  So, if the 
>> performance of the system seems acceptable with logging turned on, 
>> you should be able to let it run as long as you want, at least until 
>> you either meet you maximum file size or fill up the file system 
>> you're logging to without any additional performance impact due to 
>> the size of the log files.  Now, how to do something useful with such
large files is another question.
>>
>> Lyle
>>
>> From: Action Request System discussion list(ARSList) 
>> [mailto:arsl...@arslist.org] on Behalf Of Ramey, Anne
>> Sent: Wednesday, April 21, 2010 9:49 AM
>> To: arsl...@arslist.org
>> Subject: Log size and server performance
>>
>> **
>> We are looking at capturing more effective logging to try and catch 
>> some interrmittent problems in production that we can't seem to 
>> re-produce in test.  The problem is that the arfilter log on our 
>> server that runs escalations is currently 50M and contains about 2 
>> minutes worth of information.  This is, obviously, because of the 
>> notifications, but I'm curious as to what point I can increase my log 
>> file sizes before I start to see a perfomance hit.  Any
ideas/experiences?
>>
>> ITSM 7.0.03 P9
>> ARS 7.1 P6
>> Linux
>> Oracle
>>
>> It looks like 100M would catch a 1/2 hour of information or longer in 
>> all logs except the arfilter (but we have to set all of the log files 
>> to the same size).  500M might get us a 1/2 hour in the filter log, 
>> but the other logs will be unnecessarily big and I'm wondering if 
>> having all of the logs that size could cause server response time to
slow?
>>
>>
>> Anne Ramey
>>
>>
>> _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_
>> --
>> John Sundberg
>>
>> Kinetic Data, Inc.
>> "Building a Better Service Experience"
>> Recipient of the WWRUG09 Innovator of the Year Award
>>
>> john.sundb...@kineticdata.com
>> 651.556.0930  I  www.kineticdata.com
>
> ______________________________________________________________________
> _________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org 
> attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
>

____________________________________________________________________________
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10
www.wwrug.com ARSlist: "Where the Answers Are"

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"

Reply via email to