On Tuesday, February 20, 2018, 2:09:36 AM GMT+11, W Mainframe ***@yahoo.com [H390-MVS] <H390-***@yahoogroups.com> wrote:
 I have a question about your editor. Is there any parameter list to call the editor (from Assembler or still C) to pointing a memory structure?  Not a physical file.Â
___________________________________________
Er, no.
REVEDIT expects the DD name, data set name and volume serial, and member name if partitioned, to all be supplied before initialization.
Can't even edit z/OS UNIX files with it.
OTOH, the REVIEW browser can browse stuff in storage, but not by being passed the storage when called from another program.
Things like load module history and map information, ZIP archive directories, and LISTCAT results from the RFE 3,4 L selection code are placed in storage and browsed from there. For some of these, the REVCATCH "command" is used, as seen in some CLISTs supplied with REVIEW.
And what would an editor want with data in storage?Where should the updates be saved to?
Is the expectation that the REVEDIT internal data structures would be published such that another program would load the data into storage ready for REVEDIT to process?
Or would the in-storage data simply be used as a data source, and REVEDIT would manage its own internal data structures as per usual?
Or is something like the EDIF interface from ISPF being envisaged?
Not intending to sound snippy or anything, just trying to nail down the potential requirement details...
(A couple of times I've tried writing a program without understanding the requirement - and they've both ended up rubbish. The first time was for a product being written for CA, and the second time was at IBM. Fortunately, both times someone was able to supply the missing conceptual details.)
Cheers,Greg