ER is not supported for this object (what tha <grrrrr>)

[DBohner-(db)]

Recently, on a couple occasions, I've been working on a NER - then, suddenly... when I go back to edit it I get an error message stating: "ER is not supported for this object".

It's a dang'd NER - what do you mean ER isn't supported.

Once it occurs - I try everything (check out, check in, reboot, reboot checked out, reboot checked in, pray, prey and even (like now) ask for help)... Eventually the NER is editable - but, I don't know what 'fixes' it.

Anyone else experience this behavior (that of the NER, not my behavior)? Anyone know the quick fix?

(db)
iSeries, 8.10, 8.94.O2

 

[craig_welton]

I've seen this happen before. When editing a NER, a temp directory called TempNER is created in the spec directory of the pathcode you're working in. Sometimes this doesn't get deleted after leaving the NER editor and I kept getting the message you refer to. You want to delete the TempNER directory but that can sometimes be "locked" and it won't allow deletion; even if no OW processes are running! Then I had to reboot and delete the directory.

 

[DBohner-(db)]

Thanks Craig!

That tid-bit of info may save me (and a few others) a lot ov headaches! Next time it strikes me, I'll work to kill the TempNER dude!

(db)

 

[DBohner-(db)]

Well - I continue to be plagued by the ER is not supported flaw... This morning I'm banging away on the keyboard, compile (attempt, you can't use '"' within a NER) - then I can't get into my ner anymore.

I deleted the TempNER folder, still no good.

Any more ideas?

(db)

 

[DBohner-(db)]

The frustration only mounts.....

I've narrowed the issue down to function B9800010 - Design Event Rule.

Here's the ickie! Don't blink or you might miss part of the resolution....

I compile the function for debug, exit E1, start E1 though the Debugger... whahlaaah - I can get into the NER's Event Rules! Did you read that - I'm in... So, I exit everything - close the C debugger and go back into E1 (this time, without the debugger)... I get the error message 'ER is..."....

OK - for you C gurus; WHY!??? Why does function B9800010 work when the debugger is on, and fail when the debugger is off?

I duhnnoh - I guess I'll have to start running everything through the C Debugger?

(db)

 

[DBohner-(db)]

And the debug tracking log continues....

Within B9800010 - the following line(5895):
StartNerd(lpBhvrCom->hDlg, (LPNERDEF)&dsNERDef);

All hades breaks here... If E1 is run from the C++ Debugger, this line runs fine. If it is run 'normally' - I get my golden goose egg...

Discovered by reviewing the JDEDebug Log of a when/not starting E1 with C Debugger....

What's StartNerd??? anyone?

(db)
iSeries, 8.10, update 1, 8.94.O2

 

[Sebastien Leclerc]

You have my sympathy!!

Lets try to dig a little more...

Try to get in the offending NER in Debugger.

After the StartNerd is executed, look at the output window of the C debugger. It is possible that you see some memory exceptions or suspicious messages like this.

This is not the first time I hear something like this. i have tried to solve memory violations many times. I am pretty sure that the memory management done through the debugger is not the same as in a "non-debug" environment (anyone can confirm this?).

I have seen a case like this a few years ago. There was a limitation to the length of a single line of ER. So check your code for VERY LONG ASSIGNMENT. Like:

VA evt_szSomeVariable = "This is a very long assignment that could cause issues with the NER design. Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah Blah"

It is recommended to use Text Variables instead or to use concatenation over multiple lines of code.

 

[peter_hamilton]

Trying downloading the most revent B9800010 (maybe PG2422), as there was a bug that was fixed.