{
{    The purpose of this procedure is to re-attach (in the device management
{ sense) the specified permanent file.  The apfid and internal_cycle_name
{ (global_file_name) are used to verify that file manager and permanent files
{ are talking about the same file.  The catalog is accessed, and the fmd for
{ the file is used to re-attach the file.  The new sfid is stored in the
{ attached permanent file table.  File manager must update its tables with this
{ new sfid, and must notify the system of this new sfid.
{
{    In this version the catalog is reaccessed with the external path of
{ catalog names stored in the attached permanent file table.  This is NOT the
{ final solution, because this will not work if the name of the catalog has
{ been changed since attach time (not currently supported), or if the catalog
{ is a 'purged' catalog.  This assumes that the attach counts were cleared
{ during recovery.  They are incremented here.  This has the advantage of
{ allowing this code to be transmitted earlier than the catalog changes.  It
{ has the disadvantage of not allowing other new jobs to attach the file
{ asynchrounously to this process, since they might cause the file to go busy.
{ The internal path in the attached permanent file cannot currently be used to
{ search the catalogs since the internal catalog names are currently the global
{ file name, thus coupled physically with device manager.  Reconcilliation has
{ reassigned these names.  The final solution, I believe is to have an internal
{ catalog name that is NOT coupled with the DM global file name.  Thus this
{ internal path could be stored in the attached permanent file table, and used
{ for searching even after reconcilliation/ recovery.  In the version when we
{ have the job name and job's usage in the catalog we should verify that the
{ usage and share in the attached permanent file table match that in the
{ catalog (unless the update_catalog flag in the attached_pf_table is false)
{ and indicate an error if they do not match.  It will probably be possible for
{ the job to have the file attached multiple times.
{
{    If this is called by the client (fmp$recover_files) for a server permanent
{ file this request merely rebuilds the system file table on the client
{ mainframe (see pfp$reattach_server_file).  When the server job recovery
{ executes (fmp$recover_server_files) it calls pfp$relink_server_file which
{ causes the system file table entry to be completed on the client mainframe.
{ On the server mainframe during recovery, this interface is called to reattach
{ all permanent files on behalf of all client jobs on the client mainframe (see
{ pfp$reattach_files_for_client).
{
{       PFP$REATTACH_PERMANENT_FILE (APFID, INTERNAL_NAME, MAINFRAME_ID,
{             USAGE_SELECTIONS, SHARE_SELECTIONS, NEW_SFID, STATUS)
{
{  APFID: (input)  This parameter specifies the attached permenent file to
{        reattach.
{
{ INTERNAL_NAME: (input)  This parameter specifies the global_file_name of the
{       permanent file to re-attach.  This is used for verification.
{
{ MAINFRAME_ID: (input)  This parameter specifies the mainframe on whose behalf
{       is being done for.
{
{ USAGE_SELECTIONS: (input)  This parameter specifies the usage selections that
{       were used on the original attach.  This value should match the value
{       stored in the attached pf table.
{
{ SHARE_SELECTIONS: (input)  This parameter specifies the share selections that
{       were used on the original attach.  This value should match the value
{       stored in the attached pf table.
{
{ NEW_SFID: (output)  This parameter returns the new system_file_id assigned by
{       device manager.
{
{ STATUS: (output) This parameter returns the request status.
