Re: Telnet exit point curiosity

On Mon, 14 Apr 2003, Sean Porterfield wrote:
>
> I found Scott Klement's exit point in the archives (
> http://archive.midrange.com/midrange-l/200103/msg00068.html ) and basically
> used it as my starting point so I wouldn't have to figure out all the data
> structures.
>

Please be careful with that.  I posted that source before it was fully
completed and tested.

One really important thing is the peAutoSignOn variable.  If this gets
set to *ON, anyone can auto-signon with or without a valid password.  Make
sure you first check dsCnnPWvalid before ever setting this to '1'!!!!

Also, for the same reason, make sure that only people with *ALLOBJ
authority can compile/replace that program.  Anyone who can
register/change a telnet device initialization program (not just mine, but
any such program) can give themselves access to QSECOFR or anything
else just by setting that parameter on...


> I added on the new fields to get SSL and certificate info.  I got it to
> work, but I have some questions.
>
> This does not work (server port and SSL fields do not contain valid
> information)
>
[SNIP]
> D  dsCnnWStype                  12A
> D  dsCnnSSL                      1A
[SNIP]

True.   dsCnnWStype is at offset 25 and is 12 bytes long.   That would
put dsCnnSSL at offset 37... but it belongs at offset 40.    You need
to put something like "dsCnnReserved   3A" in between them to make
dsCnnSSL be at offset 40.

>
> I'm logging all connections to a file.  The records only show in the file if
> I end with *LR on or use FEOD.  Obviously, both of those cause a performance
> impact (I ran each possibility 10,000 times and *LR on was by far the worst
> performer.)  I thought there was a recent discussion on this somewhere, but
> I didn't find it.  When I go to production, I don't think I'll care about
> the records showing up right away.  Daily should suffice (we bring the
> system down for backup, so that should force the records into the file.)
>

Yeah, the system doesn't write the records to disk immediately, but keeps
a few of them in a buffer...   FEOD will force the buffer to be flushed to
disk.   Another way would be to do an OVRDBF FILE(MYFILE) FRCRATIO(1)

Obviously, the reason that FEOD impacts performance is that it's more
efficient to buffer the records and write them at once.  So, the OVRDBF
will probably perform similarly to FEOD. (But better than *INLR=*On)

The nice thing about FEOD is that your program can choose when to flush
the buffer instead of always doing it with every write (as with FRCRATIO)
but it doesn't sound like that would matter in your circumstance.

Here's a thread that discussed this topic in the archives:
http://archive.midrange.com/rpg400-l/200210/threads.html#00001