@USERDATA

[adewitt]

When I upgraded my Avanté to the latest release some of the processes running in Kevin's /PJSD stopped working.  It turns out that Epicor increased the number of processes subject to their security scrutiny.  Since I'm not using Epicor's scheduler my routines fail the test and were not given update rights (ACCESS DENIED).

I've figured out a way to override the security and want to set up a list of custom processes that will be allowed to override security and thus work in /PJSD.  I'm using a paragraph process to emulate the input screen.  The first thing I do load the process name into @USERDATA(9)<1>. I modified Epicor's process to load @USERDATA(9)<1> into a variable; check my list of allowed processes and if I get a hit override security.  Works great.

I'm not real familiar with @USERDATA.  Is it universal?  I realize that if I set it I should reset it at the end of my process, however, if there is another process running that uses @USERDATA(9)<1> will it corrupt what I've done (or vice versa)?

Is there a more secure way of accomplishing what I what to do; load a variable, pass it to a calling program and then reset it at the end?

Thanks.

[precisonline]

In SB+ there are two variables in that big common map that are effectively open for users to do whatever they want: @PARMS(40) and @USERDATA(10).  While @PARMS(..) is bigger and has been a part of SB+ for more years, the bigger difference between the two is how they are managed.  When you login, both variables (at all positions) are initialized to "".  From that point on, SB+ doesn't touch any element of @PARMS(..); it is completely up to the application to use it however it is needed.  So, for example, you put something in @PARMS(4) at the moment you login, it will still be there all the way until you logoff or until something comes along and changes that variable.

@USERDATA(..) however, is different.  As a primary process (screen, report, or update) is called, SB+ saves @USERDATA just like it saves @RECORD, @WORK, @KEY, @ACTION, and all those other section variables.  When the called process exits, SB+ restores @USERDATA(..) with whatever it held before the screen, report, or update was called.  So in short it's a smaller, somewhat safer place to store things that may no longer be valid after the process terminates.

So to summarize... of all the variables you could have selected, I'd say you made a wise choice.

[adewitt]

Hey thanks.

I'll load it into production and give it a try.

Al

[adewitt]

This is a long time coming but I thought I'd respond.

The problem, it turns out, is that Epicor did a lot of security validation in Avanté 9.6.4.  This validation takes the user.id and checks their USRSECMST file for access rights.  I believe this is for SOX compliance.  Well phantoms don't work in this environment.  So I have had to write routines to either circumvent this or to override security.

Epicor's answer is to use their job scheduler.  I told them I wanted a scheduler that I could launch once and it would take care itself.  This is what /PJSD does.  Specifically I said that /PJSD is what they should have wrote.

Now that I know what's happening I can work around it, but it's a pain.

[precisonline]

Specifically I said that /PJSD is what they should have wrote.

Not making any friends for me, I see.    Thanks for the smile my friend.  You know where to find me should you need.

[adewitt]

Specifically I said that /PJSD is what they should have wrote.

Not making any friends for me, I see.    Thanks for the smile my friend.  You know where to find me should you need.

I realize that I'm on a legacy system and that this is not Epicor's main focus.  However, I'm pay full price for support and some of that goes into R&D.  Hopefully R&D on my product.  So when provided tools I would like tools that, while maybe making more work in the beginning, will eventually cause less work over time.  No so with their scheduler.  It can require constant babysitting if we relied on it more.  When I first saw it I can honestly say it was a head-in-my-hands, heavy sigh moment.  When I heard about /PJSD I did say to myself "this is what Epicor should have wrote."  To this day I have no idea why they didn't.

[precisonline]

Well, what's vexing for me is that I've approached them with my tools (the download definition and schedule definition to be specific) to see if they wanted to bundle them and the response was basically "get away from me kid, ya' buggin' me.".

[adewitt]

There seems to be a definite "if it's not made here we don't want it" mentality at times.  I think I can even stretch it to "if we didn't think of it we don't want it" mentality.  We saw that when we tried to get them to incorporate some of our enhancements to a module written in the UK and finally made standard product.  We were sold "version 1" and enhanced it to drive a lot of the transaction processing to the shop floor.  Epicor's response was "well, that's not how it was originally designed so we don't want it."  So we're still using the original version (10 years old) because that's what we built out system around.

I believe they have some developers in the UK who seem pretty bright and, more importantly, think outside the box.  Maybe they'll start relying on them more.