|
Rory Hewitt wrote:
Check out this thread on the systemiNetwork: http://www.systeminetwork.com/isnetforums/showthread.php?t=45802. Although it deals with the specific issue of duplicate CONST parameters, it does include some code to allow you to get any OpDesc information without using CEEDOD... Now I don't know whether the problem with CEEDOD returning a 0 for a DS is with CEEDOD or is with the fact that the OD is passed incorrectly, but if it's the former, you could try using the following code in a copybook to bypass uisng CEEDOD:
Rory, the problem is on the caller's end; the OD is not being passed for a data structure parameter. So that alternate way of getting the OD information won't help. David, here's one way to get around the problem pre-V5R3, by defining another copy of your E-DS, so you can use it as a basis for a subfield defined LIKE. Then you pass that subfield instead. add D dataQueueEntry_getSize... add D E DS extname(EXTDSPF) qualified add D based(dummy) D dataQueueEntry... D E DS extname(EXTDSPF) qualified inz add D parm like(dataQueueEntry_getSize) add D overlay(dataQueueEntry) ... chg moreEntries = getClientData(pListId: dataQueueEntry.parm); Another way is to use a based character view of your data structure. D dataQueueEntry... D E DS extname(EXTDSPF) qualified inz add D pDataQueueEntry... add D S * inz(%addr(dataQueueEntry)) add D dataQueueEntryParm... add D S like(dataQueueEntry) add D based(pDataQueueEntry) ... chg moreEntries = getClientData(pListId: dataQueueEntryParm);
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.