Retrieving Source (DDS) from object file

70 pts.
Tags:
AS/400 development
DDS
I lost my physical source file (DDS),but its object is there.I can view the contents of it.Can I retrieve the source file(DDS) from its object?? Please help..............  

Software/Hardware used:
V5R4MO

Answer Wiki

Thanks. We'll let you know when a new response is added.

Unfortunately you cannot.

But one solution might be to use the file in a program source, than generate a compile listing and copy the specs from the listing into a new DDS scource.

——————–
There is a system API that will generate SQL/DDL source for a file object, and put it into a source file and member of your choice.

The name of the API is QSQGNDDL. This can be done through iSeries Navigator as well. Also, if you have Aldon CMS/LMi, there’s a menu option to accomplish.

Why not take this opportunity to convert your original DDS sourced object into an SQL table? The compiled SQL object will be implemented as a physical file with the same functionality as the original one compiled from DDS, and using SQL/DDL gives you more flexibility since you can utilize more of the database functionality in the future.

CWC
*********************

Discuss This Question: 9  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • ElTerrifico
    In theory, you should be able to do a DSPFFD to an outfile and then write a program to process the outfile and generate the source. I've never tried that and don't know how difficult it would be, but if you have a lot of them to recover, it may be worth exploring.
    620 pointsBadges:
    report
  • CharlieBrowne
    Here is some code that will generate output for a PF and associated LF's It can be easily modified to build you DDS or SQL source for you. * PGM PARM(&FILEIN) DCL VAR(&FILEIN) TYPE(*CHAR) LEN(20) DCL VAR(&FILE ) TYPE(*CHAR) LEN(10) DCL VAR(&LIB ) TYPE(*CHAR) LEN(10) /*-------------------------------------------------------------------*/ /* Split the parameters into their components */ /*-------------------------------------------------------------------*/ CHGVAR VAR(&FILE) VALUE(%SST(&FILEIN 1 10)) CHGVAR VAR(&LIB) VALUE(%SST(&FILEIN 11 10)) DSPFD FILE(&LIB/&FILE) TYPE(*MBRLIST) + OUTPUT(*OUTFILE) OUTFILE(QTEMP/QAFDMBRL) DSPFFD FILE(&LIB/&FILE) OUTPUT(*OUTFILE) + OUTFILE(QTEMP/QADSPFFD) DSPDBR FILE(&LIB/&FILE) OUTPUT(*OUTFILE) + OUTFILE(QTEMP/QADSPDBR) OVRDBF FILE(QAFDMBRL) TOFILE(QTEMP/QAFDMBRL) OVRDBF FILE(QADSPFFD) TOFILE(QTEMP/QADSPFFD) OVRDBF FILE(QADSPDBR) TOFILE(QTEMP/QADSPDBR) OVRDBF FILE(QAFDACCP) TOFILE(QTEMP/QAFDACCP) OVRPRTF FILE(FL001P) USRDTA(&FILE) CALL PGM(FL001R) DLTOVR FILE(*ALL) END: ENDPGM PROGRAM: FL001 FQAFDMBRL IF E DISK FQADSPFFD IF E DISK FQADSPDBR IF E DISK FQAFDACCP IF E DISK USROPN FFL001P O E PRINTER OFLIND(*IN10) C READ QAFDMBRL 99 C READ QADSPFFD 99 C WRITE HEADER *Get Physical File C IF MLFTYP = 'L' C CALL 'FL002C' C PARM MLFILE C PARM MLLIB C OPEN QAFDACCP C READ QAFDACCP 98 C WRITE HEADR1 C CLOSE QAFDACCP C ENDIF * C WRITE HEADR2 C *IN99 DOWEQ '0' C *IN10 IFEQ '1' C WRITE HEADR2 C SETOFF 10 C END C IF WHFTXT > ' ' C MOVEL WHFTXT SHFTXT C Else C MOVEL WHALIS SHFTXT C EndIf C WHFLDT IFEQ 'P' C WHFLDT OREQ 'S' C SETON 40 C MOVE WHFLDD WHFLDB C ELSE C SETOFF 40 C END C WRITE FIELD C READ QADSPFFD 99 C END *INDEX C CALL 'FL002C' C PARM MLFILE C PARM MLLIB C OPEN QAFDACCP C READ QAFDACCP 98 C MOVE ' ' FIRST C *IN98 DOWEQ '0' C APFILE ANDEQ MLFILE C FIRST IFEQ ' ' C WRITE INDEXH C SETOFF 10 C MOVE 'N' FIRST C END C APKSEQ IFEQ 'A' C MOVE ' ' APKSEQ C END C WRITE LOGICK C READ QAFDACCP 98 C END C CLOSE QAFDACCP *LOGICALS C MLFTYP IFEQ 'P' C READ QADSPDBR 99 C *IN99 IFEQ '0' C WHNO ANDGT 0 C WRITE LOGICH C SETOFF 10 C ELSE C SETON 99 C END C *IN99 DOWEQ '0' C *IN10 IFEQ '1' C WRITE LOGICH C SETOFF 10 C END C CALL 'FL002C' C PARM WHREFI C PARM WHRELI C OPEN QAFDACCP C READ QAFDACCP 98 C MOVE ' ' FIRST 1 C *IN98 DOWEQ '0' C SELECT C APMANT WHENEQ 'I' C MOVE '*IMMED' MAINT C APMANT WHENEQ 'R' C MOVE '*REBLD' MAINT C APMANT WHENEQ 'D' C MOVE '*DLY ' MAINT C ENDSL C APUNIQ IFEQ 'N' C MOVE ' ' APUNIQ C END C APSELO IFEQ 'N' C MOVE ' ' APSELO C END C APJOIN IFEQ 'N' C MOVE ' ' APJOIN C END C FIRST IFEQ ' ' C WRITE LOGICF C MOVE 'N' FIRST C END C APKSEQ IFEQ 'A' C MOVE ' ' APKSEQ C END C WRITE LOGICK C READ QAFDACCP 98 C END C CLOSE QAFDACCP C READ QADSPDBR 99 C END C END C SETON LR
    41,380 pointsBadges:
    report
  • TopKat
    DSPFFD to an outfile will work. However, it will not tell you the key fields. Do DSPFD to an outfile (DSPFD FILE(FileName) TYPE(*ACCPTH) OUTPUT(*OUTFILE) OUTFILE(YourLib/OutFileName) will list the key fields. Primary key field is first in the file, secondary key fields will follow in the proper order.
    135 pointsBadges:
    report
  • Krttrs
    Google RTVDDSSRC
    65 pointsBadges:
    report
  • Teandy
    If you have an application such as DBU, you can use it to print the file layout. You can then use the spool file to rekey the DDS or you can convert it to a text file and FTP it to your box.
    5,860 pointsBadges:
    report
  • TomLiotta
    Since a basic DSPFFD command can generate an output file with essentially all common DDS field attributes, is it really necessary to have the actual DDS? I.e., as long as the file exists (or backups exist at least), the DDS can be recreated even if manual steps are eventually involved. Is it important to have the DDS at all times? Tom
    125,585 pointsBadges:
    report
  • Sloopy
    Well, yes, Tom, there is a need to keep your source safe. It would be different if you never had source for a file which you want now to use in your project. The you have no choice. But the objects which were created by your company? That you have to maintain? I would say that having the source available and keeping it safe is a priority. It certainly IS possible to recreate the DDS or DDL source for a physical file. If it is complex, or you need to recreate source for a complex logical, then it can take a while to get it right. Remember that the format level values ought to be the same as the original file, for example, and there may be constraints, default values, all sorts of things. The APIs are there to get that information, but it soon becomes complicated. And when do you most want the source for your own objects? When there is an emergency, of course. Not the best time to start creating utilities. Any place where sources are created and maintained should have a change control system installed, and use it properly. Anyway, as to the point of the question, I pretty much agree with everything else that has been said. It just can take time to get these resurrection utilities put in place. The RTVDDSSRC utility mentioned by Krttrs has several incarnations. The best can be found as a zip file RTVDDSSRC.ZIP on this page: It's a bit old now, but it will do the job very well. Sloopy
    report
  • Sloopy
    Oh, I hate this forum's editor! The URL for the RTVDDSSRC zip file is: http://www.code400.com/forum/showthread.php?p=3770
    2,195 pointsBadges:
    report
  • TomLiotta
    ...there is a need to keep your source safe. "Source" is pretty wide ranging. Program source isn't quite like PF source, for example. Recreating PF, or even LF, source from the compiled objects isn't that hard. Output from the DSPFD TYPE() options plus from DSPFFD are easy enough to run through a few SQL statements to give a near perfect copy of DDS source. ('Perfect' would include different keywords on different lines and similar idiosyncrasies that are irrelevant.) We have at least four copies of our source in three physically different locations, including an escrow copy. I don't dispute the value of keeping source safe. It would be different if you never had source for a file which you want now to use in your project. The you have no choice. Granted. But the objects which were created by your company? That you have to maintain? I would say that having the source available and keeping it safe is a priority. Also granted, but maybe not relevant to my question which is -- is it necessary? So far, it doesn't seem to be. It certainly IS possible to recreate the DDS or DDL source for a physical file. If it is complex, or you need to recreate source for a complex logical, then it can take a while to get it right. Remember that the format level values ought to be the same as the original file, for example, and there may be constraints, default values, all sorts of things. The APIs are there to get that information, but it soon becomes complicated. That doesn't seem completely correct. The format values would normally be different if you're creating a new LF or modifying one in a meaningful way. In any case, the format levels are probably the easiest things to match. Data types types and lengths plus the buffer order is easy to ensure. The QDBRTVFD API is definitely complex. But it's really only needed for the elements that might be in a LF that are non-standard anyway. A VALUES attribute for validity checking would be an example. Whether or not such attributes should be hard-coded into a file definition is a separate issue; they indeed can exist, so must be accounted for. Two general possibilities come to mind:
    • Use DSPFD and/or DSPFFD to *Print before and after your first-cut at the new PF/LF. Run a file compare against the two spooled files to highlight differences. Easy enough to catch what you might have missed if before and after differences are flagged for you.
    • Or actually make use of the QDBRTVFD API, but only code for the specific pieces that might not appear in *outfiles from DSPFD/DSPFFD. Since the majority of stuff that gets generated is easier to handle through outfile support, venture into the API only for exceptions. And always decide if such exceptions are really proper to have in the first place.
    And when do you most want the source for your own objects? When there is an emergency, of course. Not the best time to start creating utilities. Definitely. That sounds like a very strong argument for having such a utility before an emergency arises. This thread is about just such an emergency, no? What good is it now to debate the necessity for source when it's clear that source might get lost? Worse, more once I have seen where source turned out to be wrong. Not lost, but not the "real" source -- rather it was old and obsolete or it had been modified for some enhancement/change that was never implemented. I do my best not to rely on source as the "Gold Standard". As much as possible, I use it as a short-cut. IMO, that should be standard procedure for everybody. Any place where sources are created and maintained should have a change control system installed, and use it properly. Well,... yeah. But then the question almost becomes moot. A good CMS with proper implementation should help ensure that more than one copy always exists. Promotion should be into a test or Q&A environment before being allowed to the next level. A copy should be held at one lower level even when a final promotion to production is done. If nothing else, archive copies should be automatic. An audit trail of changes should allow reconstruction. In any case, this question almost ensures that we're not talking about a CMS environment. If CMS isn't thought to be worthwhile, then where's the implied necessity for PF/LF source? It clearly isn't that important. I mean, seriously -- so far in this thread, no one even suggested to restore the source from the backup. How important is source if it isn't even backed up? Tom
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following