I will grant you that it is possible that a field reference file 'might' have had a list of values. However, SSA would not have put that in there as they do not put it in the KFP definition either. Besides, the DDS values keyword is only enforced by SDA and is ignored by all programs. This is where using a check constraint to get a list of possible values, or better yet a referential constraint to a table listing the possible values and their definitions, would be an improvement.
But you can wish in one hand and spit in the other and guess which one will fill up first.
For your initial question you are down to:
- Browsing all source for FPOTYP
- Querying KFP for all FPOTYP current values (not necessarily all POSSIBLE values)
- Buying a cross reference tool to browse all source and find the values for FPOTYP
- A combination of the above
-----Original Message-----
From: BPCS-L <bpcs-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of George Varvaressos
Sent: Monday, January 21, 2019 5:56 PM
To: bpcs-l@xxxxxxxxxxxx
Subject: [BPCS-L] Field reference file follow up FPOTYP
It should. A field reference file would have had an appropriate name and a list of values.
The point is a single source of knowledge - that was there selling point.
Some places had a full time DBA and it worked but you needed a bigger staff than most clients could afford.
It was an overhead and an approach that didn't match the client's resources.
Problem was calling it a S/38. Should have been the AS/400 from the start to show it was something completely different.
Thanks again.
--
This is the BPCS ERP System (BPCS-L) mailing list To post a message email: BPCS-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
https://lists.midrange.com/mailman/listinfo/bpcs-l
or email: BPCS-L-request@xxxxxxxxxxxxxxxxxx Before posting, please take a moment to review the archives at
https://archive.midrange.com/bpcs-l.
midrange.com
