Toby Mills

Hey guys We're turning on Resource Analzyer and I was just looking through the set of Reports that are standard. I didn't see anything that really told me which user is running what reports and how often. I'd think I could get a report that says who my heavy hitter reporting users are and how much resources it takes per report. I get that I might need a couple of reports and some drill downs. Thought I'd ask here in case and of you have already fiddled with this. Feel free to PM me if you'd rather talk privately. Thanks!

Today I got a couple of automated notes saying version 9.0.4 was updated, and 9.1 was updated. I looked at the release notes for the Client and they still don't reference 9.1 and appear (by the date in the publication) to be updated last on september 2022. the WFRS at least mentions 9.1 but hasn't been updated since November (again just looking at the text of the release notes). Anybody have word on whether this is just a faulty email delivery or was there really any new fixes that have been repackaged in 9.1? Thanks

HI David When you test this out using a test ID, do you see the new page? If so, make sure your user clears their browser cache. Something is cached up there if it's working for you but not him.

Holy cow - 16m and 24m! That's a lot of records. Maybe consider moving this to a bulk load of some sort to some SQL Database? Meantime, it sounds like the best you can do is try to save yourself some processing. After each load, you could add a ? FILE and have FOCUS send back a return code to the OS? -SET &THETIME=HHMMSS('A8');? FILE CAR-RUN-IF &RETCODE EQ 0 GOTO THEEND;-* If we fall in here, the FOCUS db is corrupted. -TYPE &THETIME ? FILE failed. FOCUS DB is corrupted. Exiting RC: 8-QUIT FOCUS 8 -THEEND-TYPE &THETIME ? FILE success. Maybe if this step in the job hits a non-zero return code, you could run a step that tries a REBUILD, REBUILD (which may not be as fast as the way you do it now to just CREATE FILE and start over). That's a tough one Richard. Let us know if you come up with any news on it. Toby

Good deal Bonnie! Thanks!

Thanks Patrick -reminds me I should come back to update this. I opened a case with the EDA guys and after conferring with the product folks, we can make use of node.js if it's installed, but on our own, we don't install node.js (or node.exe). Confirmed by Jared in support and the product division.

Hi Ric I can tell you've been digging in here. Also I can say you have a tough one on your hands based on what you've tried and not had luck. I think these 2 facts are the most interesting and rule out a lot of options: F02: Sometimes the job aborts with the U4038 error. We fix the problem by re-running the job from the delete DB step. The input data files are NOT changed. And the job runs successfully. F03: Sometimes the job completes successfully (no error indicator). But the database is corrupt, as shown with the "? file DB" command. Same fix, re-run from the delete DB step as above.My first idea was simply that you were getting too big of a dataset to read or write for FOCUS. But - F02 and F03 basically say, just run it again and all will be well. If you exceeding some boundary, I would expect that to be repeatable. So - it's not that. And worth noting is that your TEST environment does work most of the time but it DOES still fail sometimes. This is interesting. I don't know what to do that that info yet. The only thing we know that seems related is adding the new department. And - I think we can infer that there's something different about TEST and PROD. Either environmental or the way FOCUS is configured is different because TEST works more consistently than PROD. I think FOCUS is indeed the culprit who gets some non-zero return code from an OS operation and it decides to abend. You're at a tough spot. It would help if you had a dataset that you know will cause the error. Then you could just log the heck out of it and see when (perhaps with a certain sort of record) the problem occurs. First, it's been a VERY long time since I worked for the State of CA and it was core FOCUS back then too. I was only there a couple of months with IBI consulting before they moved me down to County of LA. Way back when the US launched of Operation Desert Storm and I watched CNN from a Residence Inn there. But - San Jose used to be your branch. This is getting tough enough you might need to ask for help. I suggest you open a case with IBI and be sure to point out this is core FOCUS you're talking about so you get to the right support group. If you want to pursue it on your own though, I'll pass along things to try. Your job has 2 parts right? Maybe we can narrow down the problem to which of those 2 parts is breaking. For example, you might decide to break this up into 2 totally separate jobs - each with their own JCL and so forth. You seem very knowledgeable about core FOCUS code and techniques. Add a ? FILE DB to the end of each job to see if the databases are corrupted. The goal here is not to really fix the problem - it's more to isolate it if you can. If your ? FILE shows your database has blown pointers after the payments run, then you can start working there. Next, I think I'd allocate a dataset and add some logging to my MODIFY to actually write out each record to a log file. You could set up your MODIFY to have a flag you set at the beginning to indicate whether it should be logging or not. But - since we're talking about making up 2 fake jobs anyway to test, you might just want to copy your MODIFY code elsewhere and add the TYPE ON DDNAMEs to your test focexecs. Adding the ? FILE to the end and adding the TYPE ON DDNAMEs to send messages to yourself should help you get closer to knowing where problems are. Do you think it would help to REBUILD/REBUILD in between the Payments and Deductions? I just wondered if that might help out with the pointers. I still don't have a good idea of what's happening to you. Maybe we can get closer to finding the problem using the ideas I posted above. Currently guessing data related (like non printable characters or something) or it could be some resource related thing on the os. Can you strip down to just the data from the new department? I didn't think to ask that. If we say the only new thing is the department, then maybe a syncsort kind of run to only run the new department might help too (this may be the way the data comes to you already so this might be pointless). Keep us posted. Officially I recommend opening a case or contacting your local branch (if they even still exist).

Hi Bonnie I'm not an expert on this but I can get you some info that might let you answer your own question. Basically what the error message seems to be telling you is that something is talking to your server over the port that is listening for HTTP traffic, the traffic coming in is not HTTP. By default, the HTTP port number is 8121. TCP listens on 8120 (these can be customized of course). So whatever is connecting to your server using port 8121 (unless you have a custom port which is a good idea), the traffic that comes over the wire doesn't look like HTTP. I notice the log isn't nice enough to tell you what protocol it sees, but likely it's TCP (maybe UDP). Also, here's a clue I haven't seen documented, but I'll pass it along just from experience. Watch for this sort of string: cmrpht000001 See that 'ht'? That means this is an HTTP connection. Typically for me, this means that I got on the Web Console using Chrome and I'm using HTTP to navigate around the http://machinename:8121. That's not real exciting news, but it might help other separate the cmrpip (IP - likely a TCP/IP connection like from the Client talking to the reporting server) from the 'ht' where you as an admin might be poking around. So where do you look to see your port assignments? That'll be in your odin.cfg under your server. Like if you were on windows, you'd look down here: D:ibisrv82wfsetcodin.cfg It's in the same location under the Unix world, just use your forward slashes. Make sure you're under the server and not the client folders (there's an odin.cfg in the clientwfcetc folder too). You should see the HTTP and TCP listeners spelled out for you here: ;HTTP Listener NODE = LST_HTTP BEGIN PROTOCOL = HTTP PORT = 8121 CLASS = AGENT END I would not be surprised to find out that somebody using the HTTP port instead of the TCP port. The listener for that is typically 1 number lower than the HTTP port: ;TCP Listener NODE = LST_TCP BEGIN PROTOCOL = TCP PORT = 8120 CLASS = AGENT END See if any of that helps you unravel what's hitting your box using the HTTP port and sending non-http traffic. Also it's worth considering that this could be some virus scanner your corporate folks are running. They may just see an open port and try to send random things down that pipe. Hope that helps!

Been forever for me and z/os too. I don't think we know for sure that he's loading a FOCUS database. He may just be referring to the version of FOCUS there. If you're using another database, can you post it's name and do you get any extra abend info from that? These errors are usually something like reading past the end of a file or some sort of classic abend like that. It could also be a user written subroutine that chokes on a particular piece of data. It sounds like sometimes it runs, and sometimes it doesn't . Can you tell anything useful from that? Perhaps, for example, your data has alphas every now and then in a column that's defined as numeric in a master file. It might help you home in on the problem to put in a -RUN after each steps of your job and -EXIT at places along the way to get closer to your actual problem. Watch for something that could be data related if it usually loads, but sometimes doesn't.

I flagged that post just now also. Clearly a bot of some sort. We have a way of Flagging a post but I'm not sure whether we way the Comment is inappropriate or Reported as Spam. I chose Reported as Spam.

As Mat points out, there are various logs you could use to keep up with that information. (By the way - Hi Mat! Long time no see). I think if you just need this info one time, you could scrub the logs to find an answer and kind of brute force it. If you think you're going to want to know who runs what all the time, you'll either need to enable Resource Analyzer or write a far amount of code yourself. Think about your budget and needs. With the Golden Ticket (or key or whatever we call it), you could enable RA and give it a shot for a while to see if you like it. If not, then just turn it off. You might want to check with your sales person to make sure that's okay with them, but I think they'll think it's fine. I don't know who you work for or your position, but if you can find your Account Rep that sold you WebFOCUS, this is the sort of thing they can answer.

That's great Erin! Glad you got it going. I'm still stuck in my own upgrade issues, so I'm glad at least one of us working!

That helps that you can get into the client manually through Form Based Authentication. It's been a long time since I set up an LDAP authentication/authorization, so Im just going off memory here. When you say you can't get in via SSO, are you expecting to just slide in with your windows ID and never get prompted by the Form Authorization? Lets leave App studio out of the picture till you can get there okay with your web browser. App Studio is essentially a fancy web browser that uses HTTP traffic to talk to the client. Better to just work on the web part. Do you have your main security zone set up like this? I think you don't want the Form Auth enabled. If you need to, you can edit right inside your securitysettings.xml if for some reason you have having a hard time getting back to this screen. Also I have it rolling around my head that you need to add tomcatauthentication="false" in your server.xml for tomcat (if thats what you are using. Does that ring a bell? Some logging you might try since you can get in to the client manually. Go into the admin console, choose Diagnostics and click on the Log Files. Look for this section that shows what things will show up in the event.log: Go down a little ways and turn on com.ibilog. I think that's the right thing that will make your active directory/ldap hits show up in your event.log output: I think I'd dump it up to Trace and then see if you get extra info. Try doing that and then ask your co worker to try to hit the client /ibi_apps/ web page. Once she gets re-routed to the Form Auth instead of signing in (which is what I presume is happening), turn your com.ibilog trace back to info an click on the Event.log to look inside there. See if you can see any clues. I know this is a lot of stuff to think about. I wish I could see your setup to help you but I'm in the midst of my own fires. SSO using IIS and LDAP are pretty common inside IBI. Somebody will probably be able to do a remote session with you to tell more. Assuming they get to you of course.

No problem Erin. I used to be a security guy for IBI back when I worked there. Some potential good news is that since Tibco has been purchased by Cloud Software Group, IBI gets to have it's brand name back more under it's own control. FWIW, I'm in the middle of a really mysterious upgrade problem myself from 8207 to 9.1. I have the security working though. I'm getting some IBX errors from the client interface. Those are really hard for me to debug so far. Meantime, back to you. Can you sign on at all to the client? Maybe with the 'super user' if you configured that? If you didn't have a super user configured already, let me know and maybe we can manually make one for you. Once you have that, you can start nosing around the security settings a little more. That's kind of the whole point of the super user - that ID should be able to get in even if the connection to the repository isn't quite working right (specifically so you can fix those kind of issues). Here's where you could go look to see if you have a Super user set up: Check your confwebfocus.cfg - do you see an entry for IBI_ADMIN_NAME and IBI_ADMIN_PASS?

Sounds like things are working for you, but not this other person. It's possible this is a security zone thing. in comparing your files, did you take a look at all the files that look like securitysettings*.xml? Specifically the one that says zone. Are you able to log in to the client from any machine, or are you only able to log in from a certain desktop? Make sure your user clears their browser cache too. Watch them log in via Teams or something similar. If you can take control of their keyboard via Teams, try using your ID and pw to see if you can log in from their machine. There might be a clue there. I have a trace you can turn on but first check to see if your user really has some typo or if it's maybe their machine. com.ibi.log can sometimes provide helpful info in LDAP logins to make the login process 'talk' more in your logs. We can enable that if you can tell that the user is doing everything right. Maybe have your user login from your machine to see if that works too. Sounds like you're really close to the answer so don't give up!