Changing Source Physical file record lengths

[G.Gaunt]

What is the punishment?

[gary.shipp@s3t.co.uk]

He's just doing some particularly tedious filing that I've been putting off for 18 months Actually, I don't know if that was a good idea, he'll probably end up reorganising what had previously been filed correctly.

[Guest.Visitor]

:-) As you still have the backup version, and presuming you haven't made any major changes in the new source file, try simply repeating the copy but this time use CPYSRCF instead of CPYF. Use the options FROMMBR(*ALL) MBROPT(*REPLACE) SRCOPT(*SAME) If this recovers the situation keep it quiet from the culprit for as long as possible. :-) Dave...

[byrner@sutterhealth.org]

Is there an API available to determine and extract the current library list? If not, any suggestions without calling a CLLE program?

[B.Morris]

QUSRJOBI gives the library list with the JOBI0700 format.

[gary.shipp@s3t.co.uk]

'Fraid this didn't work, still changed the dates Oh woe is me...all my carefully kept records will be destroyed forever!

[R.Daugherty]

Are you able to read the old dates and update the date fields in the new source? Ralph

[Guest.Visitor]

As it says in The Hitchhicker's Guide to the Galaxy: Don't panic! You must have done something wrong. I've just performed a test here with different length source files and it works perfectly. Are you sure of the following? a) The backup version really has the correct dates? (I hope you didn't make the copy in the wrong direction, at least not before backing up the backup.) b) Your copy from the backup file successfully replaced the members in the new file. Check the dates and times in the member descriptions. c) The Source update options parameter (SRCOPT) of CPYSRCF was set to *SAME. <blockquote><tt> Oh woe is me...all my carefully kept records will be destroyed forever! </tt></blockquote> Of course they won't. As long as you still have the backup there are several options open to you. If you can't get CPYSRCF to work, although you should be able to, as a last resort you could write an RPG program to copy one file to the other. Dave...

[Guest.Visitor]

<DIV><FONT face=Arial size=2>I think that he is talking about the member change date, not the change date on each line of source code.</FONT></DIV> <DIV><FONT face=Arial size=2></FONT></DIV> <DIV><FONT face=Arial size=2>I am not aware of any way to copy members from one file to another withoutupdating this change date. Also, there are no APIs that will update this change date either.</FONT></DIV> <DIV><FONT face=Arial size=2></FONT></DIV> <DIV><FONT face=Arial size=2>Sorry.</FONT></DIV> <DIV><FONT face=Arial size=2></FONT></DIV> <DIV><FONT face=Arial size=2>Mark Phippard</FONT></DIV> <DIV><FONT face=Arial size=2></FONT></DIV> <BLOCKQUOTE dir=ltr style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"> <DIV>"Dave Kahn" <Dave_Kahn@forums.midrangecomputing.com> wrote in message news:1f24259d.7@WebX.WawyahGHajS...</DIV>As it says in The Hitchhicker's Guide to the Galaxy: Don't panic! You must have done something wrong. I've just performed a test here with different length source files and it works perfectly. Are you sure of the following? a) The backup version really has the correct dates? (I hope you didn't make the copy in the wrong direction, at least not before backing up the backup.) b) Your copy from the backup file successfully replaced the members in the new file. Check the dates and times in the member descriptions. c) The Source update options parameter (SRCOPT) of CPYSRCF was set to *SAME. > Oh woe is me...all my carefully kept records will be destroyed > forever! Of course they won't. As long as you still have the backup there are several options open to you. If you can't get CPYSRCF to work, although you should be able to, as a last resort you could write an RPG program to copy one file to the other. Dave...</P></BLOCKQUOTE>

[R.Daugherty]

A restore from a good backup is the only answer there! :) Ralph

[Guest.Visitor]

Aha! Light bulb pings on! The member change date - that's a different story. I apologise for my obtuseness. IBM deliberately make this hard if not impossible to change because it's important audit trail information verifying that source and program really match each other. The CHGPF solution that was mooted would I think also reset this date so it's probably a non-starter. Sorry, Dave...

[gary.shipp@s3t.co.uk]

One of colleagues, while trying to be helpful, attempted to convert a source file designed for RPG III source to RPG IV i.e. 102 columns wide. Unfortunately, he did this using CPYF by copying the original file to a backup version, recreating the original file with the correct width then copying the members back into the new file. Unfortunately this process has flagged the Last Change date for each member to be today's date. The subordinate is being punished at the moment I still have the back up version of the source file containing the correct dates. Is there anyway of changing this file e.g. using CHGPF, to the correct width without effecting the dates? Thanks

[Guest.Visitor]

<blockquote><tt> A restore from a good backup is the only answer there! </tt></blockquote> Yes, but then we're back to the original field lengths. Possibly the best solution is to rename the saved source back to the original, freeze it, and create a new source file for all future development. That way all the member change dates will be correct and the programs will all point back to the correct members. What other headaches this might cause for the particular shop is another matter. Alternatively, live without the comments columns. Dave...