Wasn't sure how to best report an issue with SWAPGEN -- but here it is: Due to a Linux guest being autologged with a parm passed, the PROFILE EXEC which calls SWAPGEN twice to create 2 VDSKs had something in the stack. This caused the first invocation of SWAPGEN to fail (I believe because SWAPGEN is queueing responses to FORMAT).
For quick fix - I placed a 'DESBUF' at the top of the PROFILE EXEC to destroy anything in the stack. I thought a better fix to make SWAPGEN more invulnerable would be to use MAKEBUF/DROPBUF: 'MAKEBUF' buf = rc /* Do queuing, etc */ 'DROPBUF' buf Pushing responses for FORMAT rather than queuing would also solve... but I think MAKEBUF/DROPBUF is better. The way this showed up in the console was: FPLDSR119E Mode B not available or read only FPLSCA004I ... Issued from stage 9 of pipeline 1 name "SWPWrite" FPLSCA001I ... Running "mdskupdate LINUX SWAP B F 512" Error 119 from CMS RESERVE LINUX SWAP B: DMSRSV069E Filemode B not accessed DIAG swap disk defined at virtual address 102 (64989 4K pages of swap (failure is from 1st VDSK (101) - last line shows successful 2nd VDISK (102) ) Anyway -- for fyi and possible fya for SWAPGEN authors :-) Scott Rohling System z Linux and VM Specialist IBM Systems and Technology Group Lab Services ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
