Posts filed under 'Programming'

COBOL: “Reports of my death are greatly exaggerated.”

Having programmed in COBOL, I can say its not so bad as people think it is - and it remains a powerful force in the business world.  Thousands of lines of COBOL are being used every day.  (Of course, no one ever says thousands of lines of COBOL are being developed every day, but that’s another kettle of fish….)

Having also worked in RPG, and in APL (slightly), I can say without reservation that COBOL is not so bad.  The worst that people can say is that it takes 300 pages to write a program that C can do in one line - and they’re right.  Oh, well - can’t win ‘em all eh?

Turns out that back in September, Fujitsu updated their three COBOL compilers: one for .Net, one for Windows, and one for UNIX (including Solaris Sparc!).  It also turns out that they have released (again) a previous version for personal educational use - and at no cost!  I caught wind of this via esotechnica.  It may well be that Fujitsu has provided the easiest way to get started in COBOL anywhere.

If I’d've had Fujitsu COBOL on Microsoft Windows XP (for instance) back during my COBOL class days, they’d probably have called it cheating (heh!).

If you want to stay with open source projects, you could always use tinyCOBOL, OpenCOBOL, or GNU COBOL… although I think GNU COBOL is dead (the project was to create a COBOL compiler front-end for GCC).  TinyCOBOL and OpenCOBOL appear to be quite active (I actually packaged the tinyCOBOL RPMs for a while).

Anybody ever use COBOL for system administration?  I doubt it - but who am I to say?  Maybe that important network manager is written in COBOL and we just don’t know it…


1 comment 25 December 2007

Quickly creating large files

I’m surprised how many people never think to do this…. but it makes it quite easy.

If you need a large text file, perhaps with 1,000s of lines (or even bigger) - just use doubling to your advantage! For example, create 10 lines. Then use vi (or other editor) to copy the entire file to itself - now 20 lines. If you remember how a geometric progression goes, you’ll have your 1,000s of lines rather fast:

  1. 10 lines…
  2. 20 lines…
  3. 40 lines…
  4. 80 lines…
  5. 160 lines…
  6. 320 lines…
  7. 640 lines…
  8. 1280 lines…
  9. 2560 lines…
  10. 10240 lines…

Ten steps and we’re at 10,000+ lines. In the right editor (vi, emacs, etc.) this could be a macro for even faster doubling. This doubling could also be used at the command line:

cat file.txt >> file.txt

Combined with shell history, that should double nicely - though using an editor would be more efficient (fewer disk reads and writes).

When writing code, often programmers will want to set things off with a line of asterisks, hash marks, dashes, or equals signs. Since I use vi, I like to type in five characters, then copy those five into 10, then copy those 10 and place the result three times. There you have 40 characters just like that.

If only a certain number of characters is needed, use dd:

dd if=/dev/random of=myfile.dat bs=1024 count=10

With this command (and bs=1024), the count is in kilobytes. Thus, the example will create a 10K file. Using the Korn shell, one can use this command to get megabytes:

dd if=/dev/random of=myfile.dat bs=$(( 1024 * 1024 )) count=100

This command will create a 100M file (since bs=1048576 and count=100).

If you want files filled with nulls, just substitute /dev/null for /dev/random in the previous commands.

You could use a word dictionary for words, or a Markov chain for pseudo-prose. In any case, if you only want a certain size, do this:

~/bin/datasource | dd if=- of=myfile.dat bs=$(( 1024 * 1024 )) count=100

This will give you a 100M file of whatever it is your datasource is pumping out.


10 comments 23 November 2007

OpenSolaris on a MacBook

OpenSolaris is very interesting, and since the introduction of dtrace and ZFS has enthralled many. I tried to install it onto my HP Compaq E300 laptop (which it was unsuitable for), and tried to install it onto an HP Compaq 6910p laptop. In this case, the networking was unsupported: both the ethernet and the wireless drivers were not included with OpenSolaris Express (Developer Edition).

In any case, I expect I might just be shopping for a laptop in the next year - and it’s nice to see that OpenSolaris does run on the Apple MacBook.  This article goes into detail about how the writer got it to work, and each of the steps that were taken to make it happen.  Paul Mitchell from Sun discusses dual-partitioning a MacBook in this context as well.  Alan Perry (also from Sun) had done the same thing with a Mac Mini, and Paul extended it to the MacBook.  Both entries are detailed and have to do with MacOS X and Solaris dual-booting.

An a different note, check out the graph of library calls from dtrace in this article.  From what I’ve heard of dtrace, it’s the ultimate when it comes to debugging…


Add comment 22 November 2007

Five Reasons an Administrator Should be a Programmer Too

There are many reasons to be a programmer, but system administrators have unique reasons for having programming skills. Programming is not just useful when cobbling together shell scripts or Perl scripts, but in many other areas as well.

Consider the case of an application that stores a default directory somewhere, and changes it automatically. What happens when that saved directory becomes a removable disk, and is not changed again? The problem exhibits itself as a long wait for the system to recognize that there is no disk there before presenting a list of directories to choose from when saving a new file. The solution is to make the program choose a new default by recognizing the conditions where the program switches its defaults.

There are many reasons for a system administrator to pick up programming skills:

Programming skills translate into better scripting and further automation of system administration duties. A programmer can put together powerful scripts in Korn Shell, Perl, Ruby, or other languages - and can put them together in novel and powerful ways.

Understanding programming helps administrators to understand program failures. Like above, a program failure can be understood and thus solved easier when the troubleshooter can think like the programmer who designed the program.

With the advent of open source, it is possible to solve particularly intractable problems through source modification. A program can be modified to add new logging capabilities, breakpoints, selections, and other details. Debugging problems can happen at the source level.

Programs can be adapted or enhanced for local needs. If there are special requirements, an open source program can be modified and changed to adapt. This leads to enhanced environments that fulfill the needs of the customer.

Programming is a refreshing change from standard administration work. Putting time in on a personal programming project can refresh your spirits and recharge your batteries. If it is on an open source project much the better.


Add comment 3 September 2007


David Douthitt

David is an experienced UNIX and Linux system administrator, a former Linux distribution maintainer, and author of two books ("Advanced Topics in System Administration" and "GNU Screen: A Comprehensive Manual").

View David Douthitt's profile on LinkedIn

Top Posts

Calendar

May 2008
M T W T F S S
« Apr    
 1234
567891011
12131415161718
19202122232425
262728293031  

Recent Posts

Recent Comments

ddouthitt on Core Linux - packages
GRUBówka « Bl… on Installing GRUB on FreeBS…
monsun on Installing GRUB on FreeBS…
hictio on Core Linux - packages
locky on Installing GRUB on FreeBS…

Category Cloud

BSD Career Debian Debugging Fedora FreeBSD HPUX Learning Linux MacOS X Mind Hacks Mobile Computing NetBSD Networking OpenBSD OpenSolaris Open Source OpenVMS Personal Notes Portable Presentations Programming Red Hat Scripting Security Solaris Tips Ubuntu UNIX Wheel Group

Archives

Links