Mixing SQL- defined files and DDS files in existing model that defaults t

[Anon Anon]

[left] I would like to know the opinion of the CA forum   on possibility of using both DDS and SQL files in one model successfully . We are currently considering  building our new files  as SQL-defined in the existing model that is defaulted to DDS and we generate  COBOL functions. We are at the release  for 2E 8.1 and our System i OS  version is 5.4. We just started trying to build some functions and already encountered problems with the precompiler for the following:   EDTRCD with CRTOBJ     EXCEXTFUN is trying to find external DDS definitions .  As most of our files in the model  as of now are DDS we will have to have both SQL and DDS files in our new  functions and we are researching problems with that.

[Anon Anon]

Here's some recommended reading on this topic: http://wiki.2einfo.net/index.php?title=Using_SQL_with_2E[left]

[Anon Anon]

Thanks a lot  for the link. Very good one.  We are also going to apply SP2. It seems to solve several SQL bugs.  [left]

[Anon Anon]

[left] The Wiki article is very helpful and   it looks like it is not possible to have SQL naming in SQL-defined files  and compile functions as SQL with a mix of DDS and SQL file?  Does anybody used in real life  a mix of DDS and  SQL in the model?      I encountered lots of problems with that in the pilot I am working on  and it seems impossible to use the mix in one model and it is very unfortunate, because SQL is the way to the  future with System i.       

[Anon Anon]

Hi Folks  We are using i5OS V5R4M0,  2E 8.1 SP1 1181, S/CM 8.1 1092 (implementer 5.7 060605).  We are investigating using this exact approach, and would like to know if anyone has this working now ie. adding SQL (DDL) tables to a 2E model that has only DDS files.   Also, we plan on converting our DDS files to SQL tables, and would be interested if anyone has done this successfully.  Additionally, we use S/CM (aka implementer) for change control and some deployments to test environments, and have found a number of issues with how 2E and S/CM interact with SQL tables and views.   Does anyone have a working environment, where they can successfully checkout, promote and deploy SQL tables and views using 2E and S/CM?  Regards  Kevin.

[Anon Anon]

Hi All,  In our application we had implemented this approach. Our model has only DDS files recently we added SQL tables and application is working fine.You need to have the relations in place and then need to create SQL table (DDL file).  Thanks & Regards,Chaitanya. Message Edited by chaitanya on 10-07-2009 01:16 AM [left]

[Anon Anon]

A very interesting discussion.   We are investigating this very subject, so it's great to see that there are some people who have gone before.An attractive solution in our situation seems to be to follow the modernization techniques documented by Dan Cruickshank of IBM.   This approach converts the underlying database implementation to DDL (SQL) whilst preserving the the use logical files for existing programs meaning that the programs do not need to be recompiled.   Furthermore the SQL table is created using a new implementation name and the existing physical file is recreated as a LF (with the same format level ID) and thus supports programs and queries which previously accessed the PF.   I have seen this approach implemented by a number of tools, for example XCASE, but I am interested in seeing how best to proceed keeping the 2E in control of the DB definition.  Chaitanya, is this the approach you are working with? I notice you used the phrase "added SQL tables, did you keep a "ABFILCPP" object which is now defined as an access path?     Message Edited by MatthewMorris on 10-07-2009 12:40 PM [left]

[Deactivated User]

Hi Mat,  Have you got very far with this, or are you just in the early stages? I am very interested in what  you might come up with.  I have read Dan's document on this subject, and spent some time playing around with trying to get files to DDL, but I found that I ended up hitting limitations in the SQL code that was generated. I opened some tickets with CA, and some of them may have been addressed. It was quite a while ago though (i.e. not yesterday LOL), so I can't remember the details of the issues I ran into.  What I really wanted was files defined with DDL (both PF & LF), but still using Record Level Access (RLA). If that is what Chaitanya has achieved, I be interested in what it all looks like!  But very interested in where this is going.  Thanks,  Crispin.

[Anon Anon]

Crispin! Surely you're supposed to be providing answers, not asking questions of me?   :)  Yes, we're in the early stages.   What I am trying to do is reconcile the advice from IBM, which I read as being aimed at the lowest common denominator (RPG apps) with the "advantages" we have by using a 2E model.The more I investigate, the more I find that the burden of responsibility for managing the database shifts when using SQL, regardless of the development tools.   That said, I think that modernizing to make full use of DB2 for i 6.1 features is attractive.   At least, it holds the promise of allow incremental improvements to the system without upsetting the stability of the application.  It would seem to me that to follow the IBM advice would result in the 2E model gaining a new access path definition for each file being "modernized".   The new object would be the SQL table, the other objects (including what was the original PF) would be DDS logical files and the functions would remain unchanged, not recompiled, blissfully ignorant; Position and set LL!   That is step 1.   Subsequent steps would take on the heavy work of choosing whether to switch the 2E file to table access, do away with the logical files, recompile the programs, maybe use 2E for the indexing strategy, or maybe manage that outside of the tool... That's the complicated stuff.  The wiki article written by Ray Weeks suggests that there is little or no benefit in ditching native RLA for interactive programs. The payback for shouldering the SQL burden would seem to be in the capacity to process large data volumes.   And the anecdotal evidence suggests considerable advantage in this area.   Which it's self raises further questions, will that processing be within a 2E RTVOBJ, or externalised in to a DB2 stored procedure?  I can see the promise, but I don't want to throw the baby out with the bathwater.  Hopefully this will remain a live topic.   We're working on a system investigation at the moment, so I am sure there will be more news.   I'm hope you'll have some more insight to add.

[Deactivated User]

Hi Mat,  I hate [well, am currently disgruntled with]  this forum softwares complete disregard to thought while typing. I spent a couple of hours responding to your post while I gathered information, and then it gave me some rubbish about authentication mismatch. Then it just threw away everything (that's a change, I have managed to get it back before, not this time, grrrr...).  Anyway, to paraphrase what I spent some time typing out and thinking through...  First off, If I knew the answers to everything, it would be time to retire, as I would become quickly bored with not learning something new :)  I'm currently at V5R4, and would love to be playing with i 6.1, but we're not quite there yet, perhaps sometime later this year :)  So, this is what I was thinking.  Stage 1. No changes to 2E Model.  Replace PF/LF with DDL. In order to do this, use the  QSQGNDDL to build DDL for the 2E files after they have been compiled. Generate the LF's as Indexes (hopefully the API is good enough to set the record format and fields that are now available to be used on the CREATE INDEX statement). Then delete the DDS files, and build from the DDL.  The PF can be rebuilt form DDL maintaining the existing Format Level Id, so no need to make it an LF.I can't believe that the API won't correctly identify the RCDFMT and WHERE clauses for the CREATE INDEX statement, so it should be possible to come up with DDL defined files that have the same Level Id as well.  Then no changes need be made to any existing Program/Query that accesses the files, as they will look the same.  Question. Were you changing the PF to an LF, and then creating a new PF so that you could then use SQL from 2E, or was that purely to be able to keep the existing Format Level Id?  Anyway, enough rabmling, epsecially as I have now done this twice :-)  Stage 2...not sure yet...  Crispin.

[Deactivated User]

Mat,  I went back and read Dan's article again, it being quite a while since I last read it.  It appears that when it was written in 2006, and it appears to have some info that is not up to date.  The CREATE TABLE statement now supports RCDFMT (added in V5R4 I think). So, we don't need the LF (I mentioned that in my othjer post).  Crispin.

[Anon Anon]

Hi Crispin,  I will go and check that out.   I was under the impression that idential files would still have differing record format levels when using CRTPF vs. CREATE TABLE.  If it is as you describe, that would be much simpler for the approach I would like to take.

[Deactivated User]

Hi Mat,  There was an issue either at V5R3 or V5R4 where the DDL was creating a file with a different Format Level Id. It had to do with Date and Time data types I believe. IBM fixed this in a PTF, because if the Record Format and fields definitions are the same, the Format Level Identifier should be the same.  I currently build temporary tables in QTEMP using SQL. A typical statement might be...   CREATE TABLE QTEMP/ABCDREP AS (SELECT * FROM ABCDREP)
WITH NO DATA INCLUDING COLUMN DEFAULTS
RCDFMT FADREAT    This creates an identical Physical, except that it is has the SQL Type of TABLE. Logicals can be built over it that can then use existing 2E programs.  When I was playing with the API I was given the following DDL to create the TABLE.   DROP TABLE CBLIB/CCADREP ;

CREATE TABLE CBLIB/CCADREP (
ADADCD CHAR(3) CCSID 37 NOT NULL DEFAULT '' ,
ADABTX CHAR(25) CCSID 937 NOT NULL DEFAULT '' ,
ADACTX CHAR(20) CCSID 937 NOT NULL DEFAULT '' ,
ADADTX CHAR(25) CCSID 937 NOT NULL DEFAULT '' ,
ADAETX CHAR(17) CCSID 937 NOT NULL DEFAULT '' ,
ADAFTX CHAR(2) CCSID 37 NOT NULL DEFAULT '' ,
ADQMCD CHAR(3) CCSID 37 NOT NULL DEFAULT '' ,
ADAGTX CHAR(9) CCSID 37 NOT NULL DEFAULT '' ,
ADDBTX CHAR(9) CCSID 37 NOT NULL DEFAULT '' )

RCDFMT @ADREAT ;

LABEL ON TABLE CBLIB/CCADREP
IS 'Customer Physical file' ;

LABEL ON COLUMN CBLIB/CCADREP
( ADADCD IS 'Cust Number' ,
ADABTX IS 'Cust Name' ,
ADACTX IS 'Cust Street' ,
ADADTX IS 'Cust Extra Line' ,    ADAETX IS 'Cust City' ,                                    
  ADAFTX IS 'Cust State' ,                                  
  ADQMCD IS 'Cust                               Country' ,
  ADAGTX IS 'Cust                               Zipcode' ,
  ADDBTX IS 'DUNS ID' ) ;                                    
                                                                                     
LABEL ON COLUMN CBLIB/CCADREP                            
( ADADCD TEXT IS 'Cust Number' ,                      
  ADABTX TEXT IS 'Cust Name' ,                          
  ADACTX TEXT IS 'Cust Street' ,                      
  ADADTX TEXT IS 'Cust Extra Line' ,              
  ADAETX TEXT IS 'Cust City' ,                          
  ADAFTX TEXT IS 'Cust State' ,                        
  ADQMCD TEXT IS 'Cust Country' ,                    
  ADAGTX TEXT IS 'Cust Zipcode' ,                    
  ADDBTX TEXT IS 'DUNS ID' ) ;                              This created a TABLE (PF) that was identical to my Physical.  Anyway, I'm pretty sure that it is IBM's intent to cause the API to produce DDL that creates a PF/LF that is identical to the original.  I have followed discussions of at least one site that has replaced all their PF/LF objects with DDL defined files, without having to recompile anything, so while my testing is just observations of what I have seen, I know that this has been done in the real world as well.  Anyway, good luck with your endeavors. We're pushing for i 6.1, and I will be putting processing in place to replace the DDS compiled objects with DDL defined objects. So I'm up for phase 1 as soon as I get to 6.1 (we're even thinking about bring up a partition just to test this out).  Thanks,  Crispin.   Message Edited by Crispin on 10-09-2009 09:47 AM [left]

[Anon Anon]

Crispin, you're on to something with this.  As you describe, by including the format specification I am able to issue a CREATE TABLE which results in an file which has the same format level identifier as the original DDS.  If there is full  equivalence  then it would mean that the extended process described in the Redbook can be greatly simplified.I have been experimenting with SQL and DDS source, let me see how this works inside 2E.  Many thanks :)

[Deactivated User]

Mat,  Excellent to hear!  Honestly, the more I think about it, the more I believe it's just a case of using IBM's API to generate DDL and replace the DDS objects. This could be done as part of the 2E post compile processing, and therefore you could have 2E generating DDL defined tables/views without ANY impact on existing models.  But obviously, the proof is gonna be in the pudding :)  Crispin.

[Anon Anon]

Great thread, keep us posted.   I've been looking into this for quite a while (two years), and every time we are almost ready to start, the project gets pushed back to a low priority.   What we want to do is convert the DDS defined files to DDL to take adavantage of the performance gains from the architecture, without changing any programs yet.   Here's our plan in a nutshell: Convert DDS physical files to DDL defined tables, keeping the same format level. Create SQL Indexes duplicating as many of our logical files as possible.   (we're at V5R4, so no Select/Omit in the SQL Indexes yet, thtat's in 6.1). Recreate the logical files so they share the SQL indexes.   This way they retain their format level but use the larger page size.   The LFs are small because they don't contain the index. One other advantage to this is that if we need to change a logical file over a very large table, we can promote the index for it early so it can be built ahead of promoting the new logical file and it's programs.   We run a 24/7 critical application, so we need to keep downtime to a minimum.   Some of our large indexes take days to build. With this approach, we can do the conversions piecemeal and not have to try and do all files at once or worry about program impacts.  I did find out one thing recently that throws a possible wrench in the works.   There's a possibility that using SQL tables will increase the memory requirements of the appliaction due to the larger page size.   I hadn't seen this mentioned anywhere until just recently, and I've been reading a lot of the documentation and COMMON presentations on this.   So now we need to setup a test environment with all the major files converted so we can measure memory paging, etc. before we proceed further.   There's been a lot of resistance to SQL in our company due to some bad experiences with SQL and lock contention on another platform.  We are also looking into using a pre-compiler to conver the 2E generated DDS to SQL script automatically.   We'll keep using record level access in the programs for a while until I or someone can convince them we won't have the same lock issues as the other platform.    Feel free to e-mail if you'd like to discuss this in further detail.   And I'l be sure to keep checing this forum.  Cliff RussellCVS|[e-mail]

[Anon Anon]

Hi Cliff  You will not see any lock issue or performance issue  We have done recently mixing DDS and SQL and that is perfect and we do need to add precompilers and addition change due to SQL compilation for extsting function for compatability but that all will part of techies  RegardsMDBashir

[Anon Anon]

 Honestly, the more I think about it, the more I believe it's just a case of using IBM's API to generate DDL and replace the DDS objects. This could be done as part of the 2E post compile processing, and therefore you could have 2E generating DDL defined tables/views without ANY impact on existing models.  Crispin.   How would it deal with logicals though?   They are a sort of cross between indexes and views.   As far as I know views can not be keyed, and indexes cannot select rows or columns that would be as of v5r4.   Am I incorrect on this?

[Deactivated User]

Mark,  That had to be read in context. We were talking i 6.1, which does allow you to key views!  Crispin.

[Anon Anon]

Mark,  What I have been investigating is modernizing the database without recompiling any programs.   This is an established process described in detail by IBM, which is one of the first steps in moving from DDS to SQL.The LF's are still LF's, and the programs which read them do not need to be changed in any way because the format level identifier does not change.   The PF is replaced by a SQL table and then the logical is rebuilt from the DDS source using the CRTLF command.   The result is data which is physically stored within SQL tables, with access to the advantages of the SQE when querying the table directly. Existing programs which use native DDS file access commands read via the logical files.   RPG or COBOL programs using DDS file access can only be based over DDS logical files, they cannot "position and read" a SQL view.  From a 2E perspective I have found it easier to migrate the physical files using iSeries Navigator to create the scripts and then submit the LF's to rebuild from the DDS source.   I did not change the 2E model options to SQL, not initially.   In the test model I have been working with 2E doesn't know anything about my use of SQL so that I can maintain existing programs and have them continue to use native DDS file access.   I then experimented by changing selective views in 2E to use SQL, I targeted functions which had poor performing open query file processing.   Switching the file to SQL allowed the program to be regenerated with an embedded SQL query which performed far better than the OPNQRYFIL. Initial adoption within 2E will probably follow a similar approach of selecting individual access paths (or creating "new" ones with identical keys) which use SQL. I think also the use of the option for direct table access has an advantage in terms of fewer objects to manage by not creating view objects within the database, since the SQL query can handle most situations.  I am still experimenting with all of this, trying to work out what the best balance is to get the benefits without major disruption. I am also looking at 3rd party tools for helping with the database modernization, I don't think that it is as simple as switching from PF's to SQL tables in a single weekend, not for any serious application.  So, a simple question you asked, plus a very deep topic, resulting in a protracted reply.   What are your plans for database modernization with 2E?

[Deactivated User]

Hi Mat,  When you say that RPG cannot use SQL Views to "position and read", is this statement including the 6.1 enhancement to SQL Views?  I was under the impression that the 6.1 ability to add an ORDER BY clause to Views would allow RPG to use Record Level Access as if it was a DDS Logical. Not having 6.1 to emperiment just yet (believe me I am trying) I am unable to try this out just yet.  I would think that was a big oversight by IBM if it didn't work, but maybe I am expecting too much :)    Thanks,  Crispin.

[Deactivated User]

Or is it that Index's can have columns and select rows, I keep getting this the wrong way around :)  I'd be interested to see what the API produces for LF's at 6.1...  Crispin. Message Edited by Crispin on 02-15-2010 10:47 AM [left]

[Anon Anon]

Hello Crispin,  I have to be careful what I say, as I am doing it from memory.  In fact, I should just go back and check what I did.  I think that this was where I was trying to compile a COBOL program which used DDS file access against a "file" object which was a SQL view.  If I recall, the program would not compile, and I took this to be down to  fundamental  differences in the two types of object.  I should say, that this was taking place against the backdrop of a steep learning curve, hence the fog.  I left that issue since it was not something which I was interested in doing for real within the live system.  I am planning that LF's will stay as LF's and SQL view object will be kept to a minimum, at first, and the 2E programs which I do change will use the direct table access option.  I have heard talk of the enhanced SQL support for DDS LF's (total parity in both directions?).  Is this what you are  referring  to?  I hope that they do add this support soon.  As far as I am concerned, the less we have to worry about this kind of thing, the better.  It's a big enough job to begin to  re-engineer  the database  implementation with joins, FK's and constraints and that's where I'd like to  expend  the effort.  You are right in your other comment that the technique of using a logical file to proxy for the SQL table is no longer required since the  addition  of the RCDFMT keyword in DB2 for i SQL.  As mentioned in my earlier post, my current thinking on DB modernization of a 2E generated database is to keep 2E in the dark initially and have it continue to think that everything is still DDS.  Then, move incrementally as needed.  Since 2E always accesses the DB via logicals, this should work well, I hope.  This was all investigation up to this point, I hope to be starting the project for real in about 6 weeks time.  I will keep you posted. Message Edited by MatthewMorris on 02-15-2010 04:17 PM [left]

[Deactivated User]

Hi Mat,  It all sounds very good indeed. I will have to hope that I can access a 6.1 system sooner rather than later, so I can see for myself what can be done.  I think join LF's will be a problem, as there is no replacement as of yet, but I'm not a big fan of those things anyway :)  Look forward to hearing how it goes. Good luck!  Crispin.

[Anon Anon]

It's the joined logical files and the resulting open query files which we are most interested in targeting (eliminating?).  This model has extensive virtual fields, bad in DDS, but maybe it's about to blossom under SQL?   These are the the situations where we are looking to modify (or create  parallel) 2E access paths to be implemented in SQL.  We have experimented with this and the improvement is significant.  Of course, that's a technique which is not limited to OS/400 6.x or and can even be used over DDS objects.  But we're looking at long term evolution, so we can wait a little longer.

[Deactivated User]

Progress so far...  At V5R4 for the time being. Am now replacing PF's with TABLES as part of the compile process. Working well, and no issues associated with this so far.  Going to 6.1 this month. Will then look at replacing LF's with INDEX DDL retrieved via the API. That is when it should get interesting...  Crispin.

[Deactivated User]

Another update.

I am now generating (via a post compile processor, and thanks to a tip from Peter Verstegen)) DDL that takes the Internal 2E Field Name and uses it for the Alternate Field Name. This is then propogated to the LF's as a field Alias, which is how it appears to the end user in SQL and DB2/Web query.

The generated source for the PF looks like this...

DROP TABLE CRPU551GEN/XXAAREP ;                  
                                                 
CREATE TABLE CRPU551GEN/XXAAREP (                
Cust_Number FOR COLUMN                           
  XXADCD CHAR(3) CCSID 37 NOT NULL DEFAULT '' ,  
Cust_Name FOR COLUMN                             
  XXABTX CHAR(25) CCSID 937 NOT NULL DEFAULT '' ,
Cust_Street FOR COLUMN                           
  XXACTX CHAR(20) CCSID 937 NOT NULL DEFAULT '' ,

which leads to this in the LF's...

Field Level Information                                                   
             Data        Field  Buffer    Buffer        Field    Column   
  Field      Type       Length  Length  Position        Usage    Heading  
  XXADCD     CHAR            3       3         1        Both     Cust     
                                                                 Number   
    Field text  . . . . . . . . . . . . . . . :  Cust Number              
    Alternative name  . . . . . . . . . . . . :                           
        CUST_NUMBER                                                       
    Coded Character Set Identifier  . . . . . :     37                    
             Data        Field  Buffer    Buffer        Field    Column   
  Field      Type       Length  Length  Position        Usage    Heading  
  XXABTX     Open           25      25         4        Both     Cust Name
    Field text  . . . . . . . . . . . . . . . :  Cust Name                
    Alternative name  . . . . . . . . . . . . :                           
        CUST_NAME                                                         
    Coded Character Set Identifier  . . . . . :    937                    

Much nicer from the end user perspective, and something we were looking at doing via VIEW's. Modifying the DDL to do it this way means we don't have to create a VIEW for each file.

The other nicew thing about this is that the PF & LF's do not change their Format Level Identifier, so this can be done without any impact on existing code.

Still waiting for 6.1, but it's coming soon...

Crispin.

[Deactivated User]

Ok, so now I am running 6.1, and the addition of RCDFMT to the INDEX appears to be offering pretty much all that was promised.

There should be no reason that you could not replace LF's with INDEX's.

Couple of things.

1. QSQGNDLL is not generating the RCDFMT for the INDEX when the file is a DDS LF (I have an open PMR for that).
2. I am currently getting a slightly different Record Format Level Identifier for the DDL INDEX when compared to the DDS LF (I also have a PMR open for that).

I am hoping that these are seen as issues that can be fixed, they at least appear to be a problem to me.

Crispin.

[Deactivated User]

Update:

1. QSQGNDLL is not generating the RCDFMT for the INDEX when the file is a DDS LF (I have an open PMR for that).

This is fixed in 6.1 with PTF SI38379.

Still working on the Record Format Level Identifier issue...

Crispin.

[Deactivated User]

Latest update.

IBM has accepted my PMR as an APAR, and a PTF is in the works.

This means that I should be able to completely replace our DDS files with DDL (except for Multi-Format files, and Multi-Member Files) without having to re-compile anything.

This has been fun!

Crispin.

[Deactivated User]

Bumping thread, and an update.

I am now replacing all DDS PF/LF with DDL TABLE/INDEX, except where Multi Members, Join Specifications or Select/Omit are used. The Select/Omit usage is because the QSQGNDDL API is not currently generating the INDEX code correctly, and I have an open DCREQ with IBM for that.

Also, Simon Cockayne has taken interest and is looking at what 2E can do to match (better!) what I am doing with my processing.

Crispin.

[Anon Anon]

Crispin,

Any plans to share your solution? Pretty Please? :happy

And Tell Simon that us Plex guys would love to have DDL generated instead of DDS!

Thanks,
Charles

[Deactivated User]

Charles,

Most of what I have done has been overviewed in this thread. I basically, through post-compile processing, run the QSQGNDDL API against the file being compiled, parse the resulting DDL if it is a TABLE to add COLUMNS equal to the 2E field text (adding _ to replace blanks and non SQL compliant characters), then RUNSQLSTMT to replace the DDS object with the DDL object.

For files that cannot be moved to DDL (multi-member, joins and currently select/omit LF's) I have a Table that tells me not to process.

That's pretty much it. No magic, just sticking to a plan...

Crispin.

[Anon Anon]

I would love to see a presentation on this at the next conference in Chicago!

[Deactivated User]

Hi Mark,

I'm not adverse to presenting on the topic. I had not seen a call for presentations yet, so...

And, at this point, I think I would end up somewhat eclipsed by anything that the 2E team comes up with. Would be a shame to spend all that time putting together a presentation to find that Simon has a much better solution in his next release presentation :)

Crispin.

[Yorkshireman]

2 years on and I'm beginning to start to consider looking into this area again.

Did I miss an announcement from CA or is this all we have as public documentation.. blah blah ..


The 'project' as far as it is, is merely taking a look into how to convert DDS to DDL etc and begin to make judgements about resourcing needed for the majority of the db2 database - which is mixed 2e/rpg


Any updates / opinions / funny stories welcome.


Richard Wilson

[Deactivated User]

Hi Richard,

Look at my presentation from the Chicago user group meeting (it's in the Community Documents link at the top of the page). I fully implemented this in 2E, and my presentation tells all...

Crispin.

[Simon_Cockayne]

Hi there Charles,

Lovely to see the DDL buzz is growing!

If you want DDL on the Plex side, I strongly urge you to raise an enhancement request.

This will be reviewed by the Plex product team.

Cheers,

Simon

Simon Cockayne
CA Technologies
Principal Software Engineer
CA Subject Matter Expert
Tel: [phone]
[e-mail]

[George Jeffcock]

5 years ago and still nothing.