Row security on Version data item in F983051

Hi,

I have a client that require security on a single version, PPCM0002, of the application P03B102 for all users except one group. I intended to do this giving using Row Security over F983051 for the Version Data Item for *PUBLIC, for the range PPCM0002 to PPCM0002 with N for all the action types. However this does not work when I try to run P03B102|PPCM0002 from a solution explorer task (i.e. I can still run the version even though I should be secured out). I have changed the Data Dictionary item to allow row security. My client is on ERP8.0 SP20, with an AS/400 enterprise server at V5R2. I have attached the client jde.log.

I tried to recreate this on our own ERP8 system, and the security worked as intended. My system is SQL Server 2000 on windows 2000.

Any ideas why the row security is working OK on a windows/sql enterprise but not AS/400?

Thanks in advance,

Rob.

Hi Rob,

I'm using Xe, so it's may be not the same for ERP8, and i don't know how it works with AS400, but did you "refreshed" the data dictonnary on the as400 server ? For Windows, if you change something to a DD item, like "row security" option, you need to clear the files ddict and ddtext on the enterprise servers. Until that, the server is using old definition of the DD item. I don't know the AS400 file system but there is probably something to do the name ?

Just an idea ...

Antoine,

Thanks for the reply. On our windows 2000 system where I got the security to work successfully, all I did was delete the dddict and glbltbl spec file on the fat client where I accessed the security workbench.I did not make any changes to the server.

I replicated this for the AS/400 system but it still did not work. I support I could try removing the specs from the DV7334 pathcode on the 400.

As I said above, thanks for the response.

Rob.

EBCDIC on the iSeries deals with characters and numbers in a different order. Ie, A is greater than 0 for iSeries EBCDIC and in ASCII for Windows 0 is greater than A. This is a huge pain as security workbench is ASCII but the security kernel works in EBCDIC. What we do is either a) SQL the F00950 or b) put in multiple row conditions so that we don't mix up numbers and letters.

I would also like to point out that SP23 has true version security which sounds like is what you really need. You need some ESUs too but they aren't big.

Sue

Xe SP22Q1 iSeries V5R2 Coexistent

I won't dispute that the sort orders for EBCDIC and ASCII are different ... but in ASCII an 'A' (hex 41) is greater than a zero/0 (hex 30).

If client can handle an SP upgrade SP23 offers a new Version security