Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

Michael

About

Username
Michael
Joined
Visits
157
Last Active
Roles
Member

Comments

  • Still using OI9.4. So if the reconnect is part of OI10, it's a no-go. There's no obvious reason for the loss of network connection and nothing in any logs. Thanks for looking into it.
  • Actually using UD5.2. But the interruption is long enough to crash the program. And once it crashes, OI is totally inoperable.
  • Removed and it works. As expected.
  • Haven't done that yet. Guess I'll have to. Weird that it's ok in other environments tho. Thanks.
  • Ctrl-R and Ctrl-O both work fine.
  • Again, the MFS is Only on the SYSPROCS table, so I have no idea why it's doing this for other table searches. The other weird thing is that the identical MFS is on SYSPROCS in a test environments, and we're not seeing any problems. Trying the Ctrl…
  • I have the SYSPROCS_MFS installed on the SYSPROCS table. If someone tries to delete a source code record, from TCL or the Repository, it is blocked successfully. I never use the SRP editor. Those who do, and are using the Table Search, can no lon…
  • The plot thickens a little more. I put an MFS on SYSPROCS to prevent a delete, and it works pretty much as intended. The only problem now is that the SRP Search from the SRP Editor doesn't work any more. It's not returning the search results as b…
  • Not really but it's ok. Doing something else. Thanks for the help!
  • I would have thought that simple recompiling would have set up the SYREPOS pointers and such. Just trying it before I get further down the rabbit hole.
  • I agree about the risky part. So I put the MFS on the SYSPROCS table, and it mostly works. The delete is blocked, and the source and object code are still there. The program will still run. All good. If the user happens to delete the entity fro…
  • So I wrote the MFS and it works to prevent deletion in SYSPROCS. But if someone deletes from the OI main window, it leave the SYSPROCS record but deletes the rest and it's no longer considered a "stored procedure." To make it work again, one would…
  • Thanks anyway, sir
  • I'm definitely open to better!
  • Got it. But the authorities want to lock it down. Do I need to just write an MFS to block deletes?
  • The problem isn't GFE's. I need to compress the tables. I'm archiving 20+ years of data and the tables will need compressing badly. They actually already do.
    in Fix_LH Comment by Michael August 8
  • Thanks Jared.. If I can get it working, can it be run while the tables are in use? Other option is to run RTI_REMAKETABLE, which will Not work while in use. Thanks!
    in Fix_LH Comment by Michael August 8
  • So trying out the theory.. Fix_LH doesn't seem to work at all. It returns an error code of FS. Anyone run into this? Is there a workaround? Thanks!
    in Fix_LH Comment by Michael August 5
  • Back gnawing on this bone. I'm developing a process to archive or purge a lot of data (20 years' worth). The purge will not be a problem; but I know afterward the tables purged will be "flabby" (lots of wasted space). Plan A was to use RTI_Rema…
    in Fix_LH Comment by Michael August 5
  • Thank you sir! Sprezz was my next stop, but thanks for the direction.
    in Volume MFS Comment by Michael July 24
  • Thanks Don.. Do you know how the Writes would be coded? Would table handles, etc. still be the same? I'm sure we've all done MFS's out the wazoo, but this is new ground for me.
    in Volume MFS Comment by Michael July 24
  • Thanks. I think it's a non-issue for now. RTI_LOCK_OWNER doesn't work at all. In fact it abends OI altogether. Anyone have a workaround? Again, off-topic: the client has upgraded several of the workstations to Win10. OI still "runs", but more…
  • Actually RTI_Lock_Owner doesn't seem to work now. Quick off-topic question: We started getting a msg FS291: List over 64k bytes in BTREE.SUB operations or RELATER routines I thought the 64k issues were a thing of the past? Is this just a hold…
  • Thanks.. Most everyone who was involved at the time has moved on to other things. I'm not finding a lot of reference to it in the code, so I'm assuming not a lot was actually done with it. I'll see if I can get them to re-engage with y'all. Not a…
  • Hi Don, Will look into populating the username as you specified. The control you mentioned: does it involve the SRPMONITORCONNECT API? Thanks!
  • Was hoping there was some less-complicated.. maybe a SRP or RTI utility that could kick station-x or session-x off remotely. Something a monitor person could run w/o getting onto the server console. I'll bat those ideas around a bit. Thanks!
  • Thanks Barry. RTI_Lock_Owner does indeed get me the station ID. But the username is always Sysprog. And field 10 of Syslogins is null. The dictionary only goes to FMC 3. The client had some code that populated F10 with the user's ID, but I gu…
  • Hola all, The conventional wisdom among some of the "old-timers" with my client is that FIX_LH can actually be run while a table is in use. I know that RTI_MAKETABLE absolutely cannot, and I thought FIX_LH was the same. Does anyone know if FIX_LH…
    in Fix_LH Comment by Michael March 29
  • So hopefully-stupid question.. Are engine sessions on the engine service only created by the createengine functions, or also by the desktop application? How/should the eserver.cfg be tweaked if OI is running nearly always from the desktop? We have…
  • Looking up some of the posts on here, it seems that there are occasions when multiple OEngines can be spawned, and that in some cases the engines aren't closed when they should be. Are there settings in eserver.cfg that can/should be tweaked? All …