contemplated stupid pet tricks for pick

[fwinans]

I'm always trying to think of odd new tiny applets/tools you could make for yourself with Pick

 Here's some of the more marginal ideas -- think they'd be worth having? 

 I'm not saying I'll actually write and post these, just asking if the basic concept is glaringly wrong.

   1) have D3 listen in on a specific tcp/ip port, perhaps 3333, and keep an item in a file posted with the date/timestamp and ip addresses of the last ten contacts.
       why:  lets end-users out in the field 'ping'  your server just to 'touch home base' for some application you've whipped up.
       required feaures details:  do not be __too__ responsive -- for example after seeing a packet come in, sleep for a second before listening for more, so malicious users
       cannot bog down your server.  If they use the 'ping' command, do not bother to send a reply packet, to keep your site/service stealthy.  {erm, is more likely they'd
       use  telnet, since linux and windows  telnet both accept an desired port number like    telnet  123.45.67.89   3333    but  ping doesn't, being an icmp kinda guy.}

   2) have D3 offer simple text-only network services where when you connect you get a single line of text info, like 'what is my ip address', or 'what time is it?' or 'is it raining there?' then the connection gets dropped.  This may be a network security risk to expose on the whole internet, though, and is kinda useless on just the lan...
I'm thinking more of a telnet connection than a one-line website, here, though both would be easy.  You can download  netcat if you're coming in from a windows box,
or use the already-supplied netcat if on linux or have cygwin installed on your winbox.

  3) 'secret knock' security;  client pings a certain port on your server based on time of day, or maybe a pattern of ports, and in response they get their ip address
 added to the  'route  add   clientboxnnn   gw  192.168.0.1'   table   so they can ssh in to the main pick server, which porposely does not _have_ a default route
 set up, which frustrates hackers trying to long in using ssh and well-known userids like root or dm or guest and dumb but popular passwords like hello that your
 staff keeps using. 


  

[fwinans]

  4)  process a pool of text files that external applications are plopping into your 'inbasket' directory.  For example the really cheap downloadable utility Dosprn is made to notice it when a specific text file appears or gets fresh data, and converts the data to raster graphics data, feeding that to a locally-known windows printer.  A nice solution for using text-only winprinters for d3 print jobs, _except_  a) doesn't handle incoming jobs from multiple users well, b) you can't change to a tiny font with escape strings for wide-page reports.  If this proposed applet sat there as a demon and did the dispatching part of what dosprn does, then
more elaborate applets could be written to do the heavy lifting so the dispatcher could hopefully run fast enough to {usually} keep up without proper file locking.
Another example usage might be some email-related application, where you just want to keep a central log of what staff sent what email where, and they all agree to slap a text file in a central directory with each email they send so you can suck that text file into the central log for the day.  Also get staff to bcc: all their mail to a central email address and you could crosscheck that outgoing emails all get found {eventually} in that centrail bcc:-noted inbox, to verify the
email service is still working ok.

[Tony Gravagno]

I haven't provided the specific services you mention because I don't see a need for them, but  over the years I've done everything you propose here. Sockets, remote pings, and outside (bi-directional) messaging and requests for information are at the core of most of what I've been doing for the last decade. My private toolkit has the base code for all of this functionality. It's not a "trick", it's the air I breathe. I just wish there was as much interest for communications in the Pick market as everywhere else.

 

Or to put it another way - if you do come up with something communication-wise that might "be worth having", let me know because I might already have it in a junk drawer somewhere.

 

How's this for a stupid pet trick: Character-screen programs that do animation. I wrote two favorites. One had two dogs humping - yeah, in 80x24 ASCII. Another had a Romulan warbird flying on the screen, and the USS Enterprise coming up from the bottom. The Enterprise shoots a torpedo at the warbird which then explodes, and the Enterprise retreats back down through the bottom of the screen. Use the TCL command to send these to another port and listen for the reaction. I don't have the source for these anymore but they didn't take long to whip up.

 

T

[George Gallen]

If you running on unix, I did something similar except the listening part I did with unix using tcpdump.
 
1. create a fifo file (pipe)
2. tcpdump switches-and-stuff > fifopipe &   (have it run in the background under root)
 
From UV (also a phantom)
1. OPENSEQ "fifopipe"
2. LOOP Reading if data - process the tcp line (stripping off source and destination IP and PORT)
 
When the UV file closes, the pipe will close as well, and kill the background process - so you
always have to first start the unix end, then start up the UV process
 
It worked great when we were tracking IP hits to our server (just counts).
 
George 

---

Date: Mon, 17 Sep 2012 10:47:15 -0700
From: fwi...@sbcglobal.net
To: mvd...@googlegroups.com
Subject: [mvdbms] contemplated stupid pet tricks for pick

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

[Herb Rubin]

I use a MySQL database to cache read only data from D3. For example, when I read product data in PHP from D3, I cache it in MySQL for 10 minutes. This alleviates the Pick system from excess subroutine calls. I have a D3 system that executes 4 million subroutine calls a day so this helps a bit.

[fwinans]

  5)  As far as I know, once you find a gfe in a file, the best you can do to
       mitigate it until the next full file restore is to steal-file it into a 'trashcan'
       account of some sort. 

       There's no verb that will discard the file without putting those frames back
       into overflow.

       Marking the file as DX or DY  provides a great deal of relief,
       but eventually some hot-dog staffer will start doing all their    File-Saves
       with (XY turned on, just to be super-conscientious.  And you still have to
       use search-system in a more restrained manner to avoid 'tripping' on the GFE.

       Anyway, the stupid pet trick here would be to make new commands 
                file-save2    and       search-system2
        that always omit one 'magic'  account name, like  "GFE_TRASHCAN",
        and then struggle to make the staff use them instead of the main verbs...

[Charlie Noah]

Whatever happened to going into the system debugger and actually fixing the GFE? Can that not be done anymore on any platform? I'll admit it's been many years since I've done it (more than I care to think about), but it saved more than one file for me. Many thanks to Marcie Gebauer Miller for teaching me how to fix them instead of fearing them.

Regards,
Charlie Noah

Tiny Bear's Wild Bird Store
"Everything For The Backyard Bird Enthusiast, Except For The Birds"
http://www.TinyBearWildBirdStore.com
Toll Free: 1-855-TinyBear (855-846-9232)

[Tony Gravagno]

At least in D3, really fixing a GFE requires knowledge of specific bits and bytes in data groups and in the File Control Block (FCB). The FCB didn't exist in R83 and some of the structures are different from R83. And there are many different kinds of GFEs, each one requiring understanding and specific knowledge. I believe TL would offer a class on this with enough demand, maybe at Spectrum, or in one of their marketing/conference tours. I have no idea - can't hurt to ask.

 

I haven't seen a GFE in years. Is it worth the time to acquire that knowledge - and then forget it before getting a chance to use it?

 

T

[Tony Gravagno]

Why is basic system administration called a "stupid pet trick"? We have the source code for a file-save program and account-save program, both wrapped around a simple and well-documented Save verb. Why is it not SOP for every "value-add reseller" or system administrator to copy and distribute site-specific versions of these programs which are designed to address common specific needs? Why isn't there a FOSS page where people post simple utilities to save select pieces of a production system at specific times, thus reducing file-save and related downtime?

 

Want a search-system2? I have one that displays across a wide 132-column screen, searches IDs and/or within items. (I offered it to TL who either lost it or decided not to include the extra features - go figure.) Anyone else here have a custom search-system utility? The source is there - go for it. It's not a stupid pet trick when you're using the tools that are available.

 

T

[Charlie Noah]

I figured as much. The ones I've dealt with were in Microdata Reality and R83. Since everybody seems to have gone their own way with file structure, and everything has gotten so complex (FCB, etc.), it's probably not a skill worth acquiring. I haven't seen one in years either, knock on wood.

Charlie

--

[NEIL PRATT]

GFE now an FIE? ( File Inconsistency Encountered).  Recently encountered one or two on our new D3 rel 9 system. Actually this was about 3 weeks ago when we went live on the new release. Things have stabilized now thankfully. We had TL connect in and assist. I remember fixing GFE's way back in the heady days of R83. We used to say GFE stood for Go Fetch Eric - Don't remember Eric's last name but he was our GFE fixing guru. I fixed a few forward and backward links as well as frame size errors myself way back then but I was always nervous doing it (Reminded me of a surgeon - hand me the scalpel please). A colleague of mine developed a neat tool that would scan the entire database and find missing links and fix them. It also fixed frame size issues. As I recall his company was called InToX?

1  2595 mds > DAILY.PSL > FPSINVENTORY.MORE

1  2596 mds > DAILY.PSL > FPSINVENTORY.MORE > FPSINVENTORY.MORE

 File Inconsistency Encountered - Incorrect Links

Q=Quit/O=Logoff/S=Skip/F=Fix/T=Truncate/<CR>=Debug?

[NEIL PRATT]

Well I learned something. I didn't know the search-system command existed.

I developed a search utility that goes through a list of UV/PICK BASIC routines trying to create a cross reference file of files SELECTED, OPENed, READ from, WRITEen to CLEARED and DELETEed. I originally wrote it in UVBASIC but modified it for D3. It's not an exact science due to the myriad ways programmers use to code the different read/write etc. functions. It does help to pinpoint where a file is used especially when one has an integrated system and most I've worked on are. i.e Integrated AP,AR, GL , Order Entry, Inventory etc.

[Art Martz]

On 10/08/2012 09:40 AM, NEIL PRATT wrote:
> GFE now an FIE? ( File Inconsistency Encountered). Recently
> encountered one or two on our new D3 rel 9 system. Actually this was
> about 3 weeks ago when we went live on the new release. Things have
> stabilized now thankfully. We had TL connect in and assist. I remember
> fixing GFE's way back in the heady days of R83. We used to say GFE
> stood for Go Fetch Eric

Naw, it stands for Gone For Ever! :-)

[Tony Gravagno]

I wrote a BASIC program that completely rebuilt trashed AP/Pro systems, including all files, links, and the overflow table. This was for systems that ran out of overflow and used up the reserve frames, and for people who hit X to restore without having a verified backup. It was one of the coolest proggies I ever wrote. It was deployed from a floppy which I transferred to Support when I became QA Manager at Pick Systems - we weren't allowed to save programs on the production system. The floppy was lost soon after. I almost cried, both at the loss, and at my stupidity for not getting more copies.

 

Now THAT was a stupid pet trick, and a testament to the power of BASIC. Kudos to your colleague, Neil - I didn't know anyone else had written something like this.

 

T

[fwinans]

 Tony Gravagno wrote:

Why is basic system administration called a "stupid pet trick"?

Your Search-System is too useful {and too tedious to (re)produce}
to be a mere Stupid Pet Trick;  but mine is neither.

We routinely use a variation of File-Save where all its questions
are pre-answered, for use in overnight demon backups -- that would
be more of a borderline case, I think.

Frank

[fwinans]

  6) Running on Redhat Linux, there are 63 distinct console 'screens';
     left-alt key along with F1 to F12 will 'flip' you to /dev/tty1 through /dev/tty12,
     {also press control key if you're in the graphical desktop 'screen'}, and
     changing your grip to use right ALT key instead of the left one will add 12
     to that;  tty13 for  right_alt_key-F1 for example.  In the    man   pages, they
     refer to the right alt key of system console as the 'AltGr' or 'altgr' key;  seen
     if you Google to   keyboard layout  or to modifier key   or to  altgr  key.
     As a special case,  tty0 refers to currently 'flipped-to' ttynn.
     Although at least the first six ttynn  are tied up in mingetty  sessions via
     the /etc/inittab line items that make them accept linux logins, and another
     will be tied up if you are in runlevel 5 {graphical or 'X' mode linux}, the other
     ttynn are available for use as substitute 'dumb serial terminal' screens for
     your background pick jobs.  Also, you might want to replicate all output of
      even your normal, interactive pick sessions to a spurious ttynn screen by
     doing   d3   -114   |  tee   /dev/tty55        instead of just    d3  -114
     since this lets you do     cat  /dev/vcs55   to see a snapshot of what pick
     port 114 has on their screen right now.   The vcs55  contents will not have
     any highlighting  like boldface or inverse graphics or blinking text that you
     might have arranged on the current pick port 114 screen, and will have
     fixed length lines with  no end of line markers {no carriage return or linefeed},
     so you should do your  cat  /dev/vcs55  from an ssh or telnet session that
     has autowrap turned on and has the same screen width {80 cols by default}
     that  stty < /dev/tty55   shows.  In other words, the cat will always return
     2,000 bytes of text {80 x 25}.   This austere text representation could be handy
     for a couple of reasons;
     1)  If you want to take pick down briefly and most of the staff have gone home,
          but some are still logged in to pick, then having their sessions 
          tee'd to  /dev/ttynn  screens lets you check if they're in the  middle of some
          important transaction without having to walk over to their
          desk -- and if they're ssh'd in from a hotel room, it could be a long walk.
          Likewise, a background job's output could be spot-checked for progress.
     2)  You might someday write some application that rereads the current screen
          contents, and a vcs55 copy will thankfully not include all the myriad escape
         strings you used for cursor placement and text editing, just the end result.
         Neither will the cursor be messing up the pure onscreen text.

     The chief drawback of teeing sessions to /dev/ttynn this way is that it makes
      your  ps   listings longer, since each d3 session process has an associated
      bash process and  tee process.  I really do not think you can get around this,
      even with some clever    exec    phrasing.  The linux system 'deletes' unused
      /dev/vcsnn     entries in /dev folder, so at least keeping that folder 'tidy'  is
      not an issue.