Barry Roomberg on 12 Jan 2005 03:38:19 -0000 |
There is an opening in my company for an Associate Programmer Analyst. This is a catchall term for a variety of skill sets since we deal with such a variety of technology. In this case, it is an internal support position to start off with. I have constructed some moderately complex workflow systems that move data around an IBM MF, Linux, Solaris, and Windows boxes. I call a variety of hand coded or external programs. I glue them all together via a mixture of simple bash or Perl code. Almost all business logic is done under Linux. I download and upload files from the mainframe, and occasionally call programs under Windows when forced. This stuff basically runs itself. It can be triggered to run based on the existence of files arriving via FTP or Samba shares (Windows users drag and drop into it). There are about 30 users at this point, all moderately technical people who are employees of our company. When I roll out a new system there is a variety of documentation and training that goes along with it, depending on how complex / automated the system is and what the users need to be aware off in order to use it. The job has several areas of responsibility. The core reason for it is to provide a contact for trouble shooting and support for the users when they are having a problem. This is to keep them from calling me. I don't get a lot of calls, but when I do, it is considered a production issue, which means I have to drop everything to address it even if it is a silly issue. If there really is a problem (rather than RTFM), then you should be able to research the possible areas of concern. This means reading the logs associated with the processing, looking at files on multiple Linux or Windows systems. Most of the processing is triggered by a control file showing up, so you should be able to look at the control file (Window style ini file), check to see if files showed up, got processed to a certain step, etc. I log the hell out of everything, but since I am capturing the output of a variety of programs the logs can be very confusing. If you see a zero byte file or something like that, check for general system feel (load, memory / cpu pinned, out of space, network oddities, etc), general system troubleshooting. In this case some experience as a Linux sysadmin would be helpful. You would have to possibly read enough of my Perl code to understand what the system is trying to do. You would NOT be expected to change my code. If it hits that point that you discover a problem, and it is not based on a silly typo in a control file or a random system level event that we can't control, then you would escalate to me. If you WANT to try to fix it, and you are comfortable enough in Perl, then you could try, but only after the code is reviewed by someone else will it go into production. Keep in mind I consider myself a "passable" Perl programmer, which means the code won't make you want to rip your eyes out, but it might make you a bit nauseated. Experience with Sun Grid Engine would be a plus. Experience with the Direct Mail Industry (we print a LOT of stuff) would be a plus. Experience with Group 1 or 1st Logic software would fall into here. The ability to interview users during the construction of new systems and document workflows would be nice. The ability to understand the difference between an AFP and a Postscript print stream would be phenomenal. Not that I expect it, but if someone out there knows what I am talking about it would be very cool. If you can read a COBOL layout without flinching and you are able to resist the urge to hunt down the person who abuses the "redefines depending on" clause would be a positive. Understanding how to safely move mixed alphabetic and binary data between EBCDIC and ASCII is a definite plus. As you spend more time on the job, you would document the types of things that can be handled by our helpdesk rather than you, and work with them so they can handle the simple stuff. This is a full time position based in Ivyland PA - near Warminster. You would be on-call most of the time for support issues, but never to actually "do" the productions. Please email me your resume if you are interested. Barry Roomberg broom@cc3.com ___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
|
|