how to find the fields of a view in a system file

Hi there.

Here we do a lot of extractor/load programs, so I’m doing a few utility programs for the team.

I did one that looks into a workfile in CSV format and create a draft program in development library with the simplest structure (define data with file and layout, read work file, move fields from file to draft fields, store draft view and end)

I did another one that you define how many work files you gonna generate, with or without headers and it make another draft program in dev lib with the basics, so you lose less time with the mechanic part.

You will find them attached to this post, but they are in portuguese. Feel free to suggest any improvement or fix any bug I didn’t catch yet :slight_smile:

One of the devs asked me to make an extractor based on a view. He said it would be nice if a program could ask for a view name, and then he chooses the fields to export (like when you put a .V(SYS-VIEW) in a local/parameter module) and then it creates a draft program exporting these fields in csv format.

I took a look in a few views here, and the one that caught my attention was SYSDIC-FI-ADA.

There I found the list of views we have here, but I couldn’t manage to find the fields, neither the field attributes (format/size).

I don’t have admin profile. I don’t have access to dba libs and I can’t access any USRxxxxx modules.

Is there a way to have what I want? If there is, please help :smiley:

best regards,
EXTRAI.txt (12.9 KB)
CARGA.txt (10.7 KB)

Don’t waste your time, ask for access to the relevant USR modules - PERIOD.

You want - and get - access to the information, so why would you not get access to APIs that make your (and your organisations) life easier ?

Hi Wolfgang.
I don’t work on the organisation itself. I work for a consulting company, which maintains the systems for this organisation. They have strict security rules, mostly by the lack of knowledge of the utility, because what harm can I do using a few APIs? They shouldn’t allow the use of everything, I agree, but some are really useful… The adabas DBA works for the organisation himself and provides little to no help. Period. I honestly hate to say things like these, but it’s the truth. I really think he does have no clue on how to do these things. Or he knows and doesn’t want to help, which is pretty worse, since he wouldn’t have to do any work. Just point me to the path.

A small example was when I told him what I needed to do on the first two programs. He called me and said something like this “adabas is sensible and you shouldn’t do these things. it won’t help and can cause me problems”… So I came here and did a little research and found out that a NATRJE and a JCL EDT would make the job without his help, so I did it.

The system versioner that was developed here 10y ago, was done by another company (I didn’t work here by the time) and he once told me he has no clue on how that versioner works internally.

I took a look on a few programs available and saw several calls to modules USRxxxN, but they are not available for me, but by the comments, I can see they read the source code inside the adabas. Probably a System-fuser file or something like that.

That’s why I’m asking if there is a way to do this by the hard way.

The only way I can think to make it work by now is to make people .V a view in a local module and then run another online program passing the local name via input, then submit a job to list the local in a dataset and read that dataset in a comprehensible array to determine the fields and each field size/format and then dynamically generate a draft export program, but that’s a huge workaround and I’m convinced that must be a not-so-hard way to do this.

Most of my decades-long career has been as an independent or representing system integrators, so I am aware of how important it is to quickly befriend the DBAs when I arrive at a new client site. When teaching Natural I urge my students to do the same, because there are many tasks that are much too difficult without DBA support.

Why do you need to write and read CSVs?

Because, unless you have a very compelling case for using them (and adding semi-colon delimiters doesn’t really make a CSV), I would side with the DBA. You are intending to bill your client for many hours (considered integer and packed fields yet, or embedded special characters in text?) for utilities that don’t save your developers any significant amount of time.

If he is reading/writing a standard file, he’s almost there.

  • E L
  • .V(DDM-NAME)
  • select field list, pressing ENTR to scroll forward
  • GEN
  • SAVE pgm-name
  • add one of the following after the END-DEFINE
  ADD 1 TO #R
WRITE 'Records extracted:' #R
  ADD 1 TO #R
  IF  #ET >= 100
      RESET #ET
WRITE 'Records stored:' #R

No need for USRs, Predict exits, SYSDIC-FI, or SYSDIC-EL. No home-grown utilities.