Is it possible to determine the SBX a different job is running.

I'd like to update ATEINS to display both the program and the SBX of each job.

Yes and no.

There is currently a field LASTSBR in the JOBTBL record (see ASHINC:JOBTBL.MAP or .SDF) which holds 6 characters worth (4 RAD50 bytes) of the last XCALL name. You can see it in JSTAT...



But there are a couple of shortcomings in the way it is currently implemented vs. what you want to do. The first is that it only gets updated when a new XCALL occurs, not when it returns, so you can't easily tell if the job is currently executing that SBX, or has returned from it (which may mean that it's either in the main program or another SBX or SBR).

The second is that it only holds 6 characters, whereas like programs, SBX names can now go to 10.

The current JOBTBL layout is years overdue for a makeover, but I've been postponing it because of the disruption it would cause for incremental upgrading. (You'd have to get every user out, and make sure the JOBTBL.SYS was removed, before you could launch a version using the new layout.) Alternatively, we could also rename the JOBTBL.SYS file at the same time, so that new and old versions could co-exist, but they would be in separate JOBTBL universes. (They could still share locks, so maybe that's not a horrible approach, but it would probably cause issues for applications that scan the JOBTBL for purposes such as detecting whether a background server needs to be launched

I suppose we could get fancy with a side-car JOBTBL2.SYS which only be recognized by the newer version, but given how critical the JOBTBL is, adding overhead and the complexity of another file doesn't seem like a great idea.

The other option would be to re-purpose an underused field in the existing layout. In this case, we might simply redefine that LASTSBR field to mean "current SBR/SBX". (Arguably that would be just as useful, if not more so, than the current "last SBR/SBX".) But if we wanted the full 10 characters, we'd need to scavenge for some extra space.

The most likely candidate is a message buffer, currently 89 bytes (it has already been whittled down from it's original 128 bytes). That buffer is only used for inter-job messaging (i.e. SEND.LIT, FORCE.LIT and ITC.SBR), none of which is very commonly used, and to the extent that they are used, we don't know whether the last N bytes are ever used.

So we could probably steal the last 10 of them, but there would be some danger that maybe some application is using those bytes in an inter-job messaging utility. I guess we could get clever and detect whether the upper 10 bytes were ever used by setting a flag byte at, say, position 79; once that byte got changed, we could then stop updating the upper 10 bytes. But it starts to get rather byzantine after going down this path very far.

I'm open to a suggestion though, and maybe it even merits a few minutes of group discussion and vote at the Conference?

That confirms what I thought.

We can discuss at the conference over a round!

Should the AF_SBXASRUN flag update the current program field in the job table to the SBX?

Currently it doesn't. It's open to debate whether it should.

One argument for not updating it is that unlike the case with a real RUN, you are typically only running one at a time, i.e. they aren't nested. But with SBXs, they can be nested, so it might seem misleading to show that the program is running "XXXXX" when in fact it is running "AAAAA" which called "BBBBB" which called "CCCCC" ...

I think I would prefer changing the meaning of the "Last SBR" field to be "Current SBR/SBX", and scavenge the extra bytes needed for the full name (or maybe just live with recording the first 6 bytes of the name).

This hasn't been resolved. We have more of an issue not knowing what program users are in because the dialog is an SBX, and ATEINS shows the menu program that launched it. As you stated it's more complicated than just updating the current/last because you could be nested some number.

Perhaps, the simplest solution would be to update the program to be the current SBX if AF_SBXASRUN. I can think of search subroutines setting AF_SBXASRUN that I might not want to update the current program field, but I'm not sure there's a reason to do a lot of work to add a mechanism to change this behavior.

I don't think that MX_CALLSTACK is accessible to any job other than the current one. Is that correct?

Your suggestion seems simple enough, but I am somewhat worried that there could cause some other problem to surface down the road.

That might also be true of taking 10 bytes out of the message field to store the current SBX, but that approach seems slightly more useful and slightly less dangerous. (Odds are very high that no one has ever used bytes 75-84 of the message field; it's mainly there for SEND.LIT to send short messages like "Please Log Out - System Rebooting".)

It's also true that MX_CALLSTACK is only accessible to your own job; one way to extend that might ironically be to use the message field in the job control record, but it would require a lot more than 75 or 84 bytes. (If we were to implement such a function, it would probably make the most sense to tell the target job to just output it to the ashlog, or some other file, where the requester can then examine it.)

Let me sleep on it and if I don't have too many nightmares, I'll shoehorn this into the 7.0 "stable release".

If it's only current SBX, I don't think it's worth in effort. The same problem of having no idea what program the user is running is.

Using your example, the program running is "XXXXX" when in fact it is running "AAAAA" which called "BBBBB" which called "CCCCC". If exiting "CCCCC" doesn't update the current sbx to "BBBBB", this is no more useful than the current situation.

It's probably not worthwhile to make a change if no one else is concerned with this.

I woke up thinking that I didn't have any nightmares so we're clear to proceed. But now I'm wondering if I just slept through them. What I was planning, and can implement very simply, was to add the current SBX to the job table.

As an aside, we already have the current program name, with the one exception being that XCALL AMOS doesn't update it. (Should that be treated as a bug and fixed? Or left as a feature?)

I'm still undecided as to whether using the AF_SBXASRUN status to treat an XCALL SBX as equivalent to a RUN is a good idea. If you're using RUNSBX.LIT to launch SBXs that are effectively main programs, then perhaps it would be desirable to see that first SBX as the 'main' program, rather than RUNSBX. (By analogy you wouldn't want to treat RUN.LIT as the main program either.) But since AF_SBXASRUN has other purposes, it's not at all clear that glomming on to it for a different purpose is a good idea.) It might make more sense to treat RUNSBX as a standard and a special case. But in that case, it really should be a standard that anyone can use. (Judging from the size of yours, it probably has a bunch of proprietary logic that only makes sense to you.) Or, add another AF_xxx flag that can be used to elevate an XCALL SBX to main program status?

A side note on the existing XCALL in the job table: it refers to the last internal XCALL; it does not get cleared on return from that xcall. That was a deliberate choice, on the theory that most internal xcalls are so quick that you wouldn't ever see them in something like JSTAT; yet it might be useful to know what the last xcall was. And you can tell from the location counter whether it is actually in the XCALL or not. (Assuming of course you have LSX handy; perhaps it would be nice to add some kind of flag indicating whether the job is still within that internal xcall or not.)

But to go back to the SBX issue, my plan was to just add the equivalent of the existing .SBXNAME dot variable value to the job table. It already works like a stack, so that in your example, if AAAAAA.RUN calls BBBBBB.SBX that calls CCCCCC.SBX, on return from CCCCCC the current SBX name reverts back to BBBBBB. On return from BBBBBB back to AAAAAA.RUN, it gets cleared entirely. So a utility like JSTAT would be able to show the the current SBX (if applicable) just like the ashlog traces do.

Does that address your concern? Or are you hoping to be able to see the entire call stack remotely? As mentioned previously, we could implement that, but it would have to be done by getting the target program to output its own call stack to some kind of file that could be read by the source program.

One other caveat that I should mention: my plan was to not force a job table update on every xcall/return. Instead, the updates would occur on the existing schedule (every few seconds). So if the main program did a lot of very short SBX calls in rapid succession, a utility like JSTAT might never actually see them.

Our version of RUNSBX has an optional /ATE switch to use Fn'ATE'SBX(). We have some differences in our version of fnatesbx.bsi.

The only reason I mentioned MX_CALLSTACK was to verify we couldn't implement this ourselves if necessary.

I think the solution you suggest using .SBXNAME with a new job table is fine.

I was hesitant to ask for another switch with AF_SBXASRUN because it is just one more thing deal with, and I thought most of our programs that use it would be fine to replace the current program name.

I guess we can't know which approach is more problematic until someone updates from a previous version and has to deal with the different job table.

Just to reiterate, the following option is what I agree with.

Ok, let's start with the part with agree on. I should be able to roll it out tomorrow.

Here's an update that implements the above. I haven't yet decided what to do about the SBXRUN or XCALL AMOS issues, but at least you'll have the current SBX. Note that you'll need to use UPDCUR to bring down the updated version of JSTAT that shows it.

ash-7.0.1753.0-el7-upd.tz
ash70notes.txt

JSTAT 3.3 (114) doesn't work well with EL7 7.0.1754.3/64. The initial load of information from the passed job takes 30-60 seconds. The 2nd update also takes a long time, while the elapsed time doesn't change. If it does change it increases by 1 second.

It's also interrupting the other job. The focus in the other job was on an INFLD, every time just before JSTAT updated the cursor would move to the far left column and middle vertically. I could type like it's the same INFLD.

Just a quick update to confirm that I'm able to reproduce this. Appears to be purely a 64 bit issue. Am investigating...

Still trying to figure this one out...

This remains elusive. It doesn't seem to happen in CS8 or the Ubuntu versions, making it appear to be specific to EL7/64. But it's not clear just what the issue is, although by trial and error it appears that it is related to the SIGUSR1 signal sent from JSTAT to the target to get it to respond more quickly. As a possible/temporary workaround I've added /NOSIG switch to JSTAT 3.3(115) to disable the signal, which seems to eliminate the issue here. The downside is that the initial response will take up to about 20 seconds, or whatever the current IJCFREQ setting is. You can speed that up by explicitly setting IJCFREQ in the miame.ini. Perhaps something on the order of 7 seconds would be acceptable.

The updated JSTAT is available via UPDCUR.

OK, I think I finally figured this out. The problem was buried in the signal handler used by XCALL ITC (which is used by JSTAT, SEND, FORCE, etc.).

ash70notes.txt
ash-7.0.1756.2-el7-x86_64-upd.tz
ash-7.0.1756.2-cs8-x86_64-upd.tz
ash-7.0.1756.2-d12-x86_64-upd.tz

Thanks for updates, Updated my CS8 to A-Shell 7.0.1756.2/64.

EL7 - 7.0.1756.2/64 resolves this for me. Thanks for the diligence.